Generate porting.info in build tree rather than source tree
Torbjorn SVENSSON
torbjorn.svensson@foss.st.com
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 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.
More information about the Newlib
mailing list