Re: Generate porting.info in build tree rather than source tree

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 porting.info file
> 
> porting.info 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 porting.info 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:
>> https://developer.arm.com/-/media/Files/downloads/gnu-rm/10.3-2021.10/gcc-arm-none-eabi-10.3-2021.10-src.tar.bz2
> 
> 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 porting.info, but not libc.info, libm.info 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/Makefile.in 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.