From: Mike Frysinger <vapier@gentoo.org>
To: Torbjorn SVENSSON <torbjorn.svensson@foss.st.com>
Cc: newlib@sourceware.org
Subject: Re: Generate porting.info in build tree rather than source tree
Date: Sun, 30 Oct 2022 12:57:18 +0545 [thread overview]
Message-ID: <Y14j0uavNo3Mnq1Z@vapier> (raw)
In-Reply-To: <407c1d77-494e-b091-3390-4e8415631056@foss.st.com>
[-- 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 --]
next prev parent reply other threads:[~2022-10-30 8:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-28 15:40 Torbjorn SVENSSON
2022-10-29 13:32 ` Mike Frysinger
2022-10-29 15:38 ` Torbjorn SVENSSON
2022-10-30 7:12 ` Mike Frysinger [this message]
2022-10-31 15:10 ` Torbjorn SVENSSON
2022-11-04 0:29 ` Mike Frysinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y14j0uavNo3Mnq1Z@vapier \
--to=vapier@gentoo.org \
--cc=newlib@sourceware.org \
--cc=torbjorn.svensson@foss.st.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).