Generate porting.info in build tree rather than source tree

Generate porting.info in build tree rather than source tree

[Torbjorn SVENSSON]

Hello,

With the recent improvements in the build system by Mike Frysinger, I've 
noticed a minor regression.

When building newlib, the file libgloss/doc/porting.info is always 
created in the source tree rather than the build tree. Looking at the 
libgloss/Makefile.* files, it appears that this is derived from the 
libgloss/doc/Makefile.inc line:
info_TEXINFOS += %D%/porting.texi

To my knowledge (no automake wiz...), %D% is a relative path, so I 
suppose the generated path should not use $(srcdir), yet the Makefile.in 
does contain $(srcdir)/doc/porting.info.

Would it be possible to have this porting.info file generated in the 
build tree rather than the source tree to avoid having the source tree 
in a dirty state after a build?

I've spotted this building newlib for arm-none-eabi.

Kind regards,
Torbjörn

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]

On 28 Oct 2022 17:40, Torbjorn SVENSSON wrote:
> With the recent improvements in the build system by Mike Frysinger, I've 
> noticed a minor regression.

this is not new behavior.  you can check out newlib-4.1.0 which doesn't
contain any of my build changes and it does the same thing.

> When building newlib, the file libgloss/doc/porting.info is always 
> created in the source tree rather than the build tree. Looking at the 
> libgloss/Makefile.* files, it appears that this is derived from the 
> libgloss/doc/Makefile.inc line:
> info_TEXINFOS += %D%/porting.texi
> 
> To my knowledge (no automake wiz...), %D% is a relative path, so I 
> suppose the generated path should not use $(srcdir), yet the Makefile.in 
> does contain $(srcdir)/doc/porting.info.
> 
> Would it be possible to have this porting.info file generated in the 
> build tree rather than the source tree to avoid having the source tree 
> in a dirty state after a build?

this is WAI.  info files are distributed with releases, so it should be
generated in the source tree.  this is documented here:
https://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets
> 'info'
> Normally a GNU distribution comes with Info files, and that means the Info
> files are present in the source directory. Therefore, the Make rule for an
> info file should update it in the source directory. When users build the
> package, ordinarily Make will not update the Info files because they will
> already be up to date.
-mike

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Torbjorn SVENSSON]

Hi Mike,

Thanks for your reply.

On 2022-10-29 15:32, Mike Frysinger wrote:
> On 28 Oct 2022 17:40, Torbjorn SVENSSON wrote:
>> With the recent improvements in the build system by Mike Frysinger, I've
>> noticed a minor regression.
> 
> this is not new behavior.  you can check out newlib-4.1.0 which doesn't
> contain any of my build changes and it does the same thing.
> 
>> When building newlib, the file libgloss/doc/porting.info is always
>> created in the source tree rather than the build tree. Looking at the
>> libgloss/Makefile.* files, it appears that this is derived from the
>> libgloss/doc/Makefile.inc line:
>> info_TEXINFOS += %D%/porting.texi
>>
>> To my knowledge (no automake wiz...), %D% is a relative path, so I
>> suppose the generated path should not use $(srcdir), yet the Makefile.in
>> does contain $(srcdir)/doc/porting.info.
>>
>> Would it be possible to have this porting.info file generated in the
>> build tree rather than the source tree to avoid having the source tree
>> in a dirty state after a build?
> 
> this is WAI.  info files are distributed with releases, so it should be
> generated in the source tree.  this is documented here:
> https://www.gnu.org/prep/standards/html_node/Standard-Targets.html#Standard-Targets
>> 'info'
>> Normally a GNU distribution comes with Info files, and that means the Info
>> files are present in the source directory. Therefore, the Make rule for an
>> info file should update it in the source directory. When users build the
>> package, ordinarily Make will not update the Info files because they will
>> already be up to date.
> -mike

Okay, so in that case, something changed in the newlib build process to 
generate and install the porting.info file 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

In the tarball, there is a build-toolchain.sh that builds newlib using:

  $SRCDIR/$NEWLIB/configure  \
         $NEWLIB_CONFIG_OPTS \
         --target=$TARGET \
         --prefix=$INSTALLDIR_NATIVE \
         --infodir=$INSTALLDIR_NATIVE_DOC/info \
         --mandir=$INSTALLDIR_NATIVE_DOC/man \
         --htmldir=$INSTALLDIR_NATIVE_DOC/html \
         --pdfdir=$INSTALLDIR_NATIVE_DOC/pdf \
         --enable-newlib-io-long-long \
         --enable-newlib-io-c99-formats \
         --enable-newlib-reent-check-verify \
         --enable-newlib-register-fini \
         --enable-newlib-retargetable-locking \
         --disable-newlib-supplied-syscalls \
         --disable-nls
     make -j$JOBS
     make pdf
     make html

According to the build I did yesterday of a more recent snapshot of 
newlib (bfee9c6ab0c3c9a5742e84509d01ec6472aa62c4), the porting.info file 
is generated by the "make -j$JOBS" command.

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?

Kind regards,
Torbjörn

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1829 bytes --]

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.

> 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.

> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Torbjorn SVENSSON]

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.

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

On 31 Oct 2022 16:10, Torbjorn SVENSSON wrote:
> 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?

the GNU project provides no such target/config.  you can prob cheat by
setting MAKEINFO to a stub program.  or just build the info pages.  i
don't see why building them is a problem in the first place.
-mike

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]