public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: Jon Turney <jon.turney@dronecode.org.uk>
Cc: "newlib@sourceware.org" <newlib@sourceware.org>
Subject: Re: [PATCH 1/7] newlib: move AC_NO_EXECUTABLES logic up to common code
Date: Wed, 9 Feb 2022 23:25:43 -0500	[thread overview]
Message-ID: <YgSTx7mFtp3obegW@vapier> (raw)
In-Reply-To: <48be44ec-5051-3f60-279b-ae53500559e5@dronecode.org.uk>

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

On 09 Feb 2022 19:42, Jon Turney wrote:
> On 05/02/2022 07:34, Mike Frysinger wrote:
> > This logic was added to libc & libm to get it working again after some
> > reworks in the CPP handling, but now that that's settled, let's move
> > this to the common newlib configure logic.  This will make it easier
> > to consolidate all the configure calls into the top-level newlib dir.
> > 
> > This does create a lot of noise in the generate scripts, but that's
> > because of the ordering of the calls, not because of correctness. We
> > will try to draw that back down in follow up commits as we modernize
> > the toolchain calls in here.
> 
> Somehow, this change seems to prevent a self-hosted cygwin build from 
> working.
> 
> See e.g. https://github.com/cygwin/cygwin/runs/5118411294
> 
> Comparing this with the previous successful run, it looks like:
> 
> Because doc/makedoc appears in noinst_DATA, which the target all depends 
> on, it tries to make the target doc/makedoc (without EXEEXT_FOR_BUILD 
> appended), which uses a one step built-in(?) compiler rule, and fails as 
> the directory $builddir/doc/ doesn't exist yet.
> 
> Note that 'make info' still works, as this properly depends on $(MKDOC).
> 
> So maybe something like this is needed?  But I have no idea what this 
> change did to stop it working as before...
> 
> > --- a/newlib/doc/local.mk
> > +++ b/newlib/doc/local.mk
> > @@ -1,8 +1,8 @@
> > -# We can't use noinst_PROGRAMS, because automake will add $(EXEEXT).
> > -noinst_DATA += doc/makedoc
> > -
> >  MKDOC = doc/makedoc$(EXEEXT_FOR_BUILD)
> >  
> > +# We can't use noinst_PROGRAMS, because automake will add $(EXEEXT).
> > +noinst_DATA += $(MKDOC)
> > +
> >  # We don't use CFLAGS with CC_FOR_BUILD because here CFLAGS will
> >  # actually be CFLAGS_FOR_TARGET, and in some cases that will include
> >  # -Os, which CC_FOR_BUILD may not recognize.

i don't have an answer off the top of my head as to why it was working but
now is not, but if we focus on the failures, i think we have bugs regardless
here that should be fixed.

first your change here looks correct.  but i don't think it suffices.  we
also need the actual .def files to depend on the tool since they need it to
exist.  i'll push a fix shortly.
-mike

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

  reply	other threads:[~2022-02-10  4:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-05  7:34 [PATCH 0/7] modernize toolchain macros Mike Frysinger
2022-02-05  7:34 ` [PATCH 1/7] newlib: move AC_NO_EXECUTABLES logic up to common code Mike Frysinger
2022-02-09 19:42   ` Jon Turney
2022-02-10  4:25     ` Mike Frysinger [this message]
2022-02-10  4:27     ` [PATCH/committed] newlib: fix mkdoc dependencies Mike Frysinger
2022-02-05  7:34 ` [PATCH 2/7] newlib: switch to standard AC_PROG_CC Mike Frysinger
2022-02-05  7:34 ` [PATCH 3/7] newlib: switch to standard AM_PROG_AS Mike Frysinger
2022-02-05  7:34 ` [PATCH 4/7] newlib: switch to AM_PROG_AR Mike Frysinger
2022-02-05  7:34 ` [PATCH 5/7] newlib: drop cygnus EXEEXT hack Mike Frysinger
2022-02-05  7:34 ` [PATCH 6/7] newlib: drop autoconf-2.13 hack Mike Frysinger
2022-02-05  7:34 ` [PATCH 7/7] newlib: switch to standard AC_PROG_RANLIB Mike Frysinger
2022-02-08 10:10 ` [PATCH 0/7] modernize toolchain macros Corinna Vinschen

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=YgSTx7mFtp3obegW@vapier \
    --to=vapier@gentoo.org \
    --cc=jon.turney@dronecode.org.uk \
    --cc=newlib@sourceware.org \
    /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).