Generate in build tree rather than source tree

Mon Oct 31 15:10:36 GMT 2022

On 2022-10-30 08:12, Mike Frysinger wrote:
> On 29 Oct 2022 17:38, Torbjorn SVENSSON wrote:
>> Okay, so in that case, something changed in the newlib build process to
>> generate and install the file
> is part of libgloss, not newlib.  i understand the source tarball
> is packaged overall as "newlib" so it can be a little confusing.
> older versions build & install if you use the install-info target.
> but it wouldn't do it by default.

Might be so, but not for the default make target (the one I used). What 
make target should I use to build everything, just like the build system 
did before your improvement, but avoid the .info files?

>> as it was not required in the
>> Arm snapshot included in their 10.3-2021.10 release (commit
>> 2a3a03972b35377aef8d3d52d873ac3b8fcc512c in newlib tree).
>> You can find the source tree of the 10.3-2021.10 release here:
> i'm not super interested in random vendor drops, so i won't bother looking.

It was just used as a reference to where I got the commands from, so no 
need to check the tarball if you don't want to.

>> Please note that I do get, but not, or
>> any other .info files in my build. I suppose a build should generate all
>> .info files or none from the source tree?
> newlib calls AM_INIT_AUTOMAKE(no-installinfo).  this is a holdover from when
> newlib was using AM_INIT_AUTOMAKE(cygnus) which implies no-installinfo.
> libgloss has never used cygnus nor no-installinfo with automake.  but it also
> wasn't really using automake files in subdirs (like the doc/ dir).  and the
> hand-written libgloss doc/ didn't build+install it by default.  so
> when i converted it to automake, that was subtly enabled by default.
> imo we should have these enabled by default in newlib for libc & libm as it
> aligns with the GNU project standards.  anyone shipping releases should have
> the info pages includes so end devs don't generate it themselves.  if you're
> building from git, then having extra tools is kind of expected.
> -mike

My main concern is that these .info files were treated differently and 
that the 2 builds produced different file sets.

Anyway, I saw your patch and I think it makes more sense to have all 
files, or none that some of them.

It would be nice if this was an option to the build system, but I 
suppose that would require some more work/time.

More information about the Newlib mailing list