From: Nicholas Wourms <nwourms@myrealbox.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb <gdb@sources.redhat.com>, binutils <binutils@sources.redhat.com>
Subject: Re: parallel builds failing in bfd
Date: Wed, 28 May 2003 22:51:00 -0000 [thread overview]
Message-ID: <3ED53CC0.9040305@myrealbox.com> (raw)
In-Reply-To: <20030528220621.GA24942@nevyn.them.org>
Daniel Jacobowitz wrote:
> On Wed, May 28, 2003 at 03:01:48PM -0700, David Carlton wrote:
>
>>Every once in a while, when I do a parallel build from the top level,
>>I get a failure that stems from bfd.h being built incorrectly. Do
>>other people run into this problem? I'm not at all familiar with
>>bfd's Makefile.in, so I don't know offhand what might be causing this
>>problem.
>
>
> It's an autoconf 2.13 bug unfortunately. It will be fixed after the
> 2.5x transition, which is starting to gain a little momentum now.
>
BTW, are there any plans to transition to Automake-1.7.X &
Libtool-1.5.X, now that they have stabilized? It sure would be nice to
finally have a consolidated, streamlined build without all this leftover
Cygnus tree building crap. Yes, I dare say to ditch the current cruft
which is polluting Makefile.in's. There should be no reason why the
entire configury can't happen in one shot. Yes, I am aware that it must
support mixed trees, which is why one would put conditional guards
around subproject macros, running them only iff said subproject
directory is present in the source tree. It would save time and, for
some, resources [since repeatedly calling the Autom4te/Automake perl
functions (when checking for autoheader, etc.) tends to hog resources].
Not to mention the fact that {in-tree,parallel,distcc} building is
*much* easier to implement and less prone to break with the latest
versions of these tools. The biggest advantage, by far, would be to
bring subproject Makefile templates inline with some sort of general
standard, which is generally enforced by the current Automake/Autoconf
macros (whereas previous versions of autoconf/automake were rather lax).
Just my $0.02... Feel free to disagree :-)
Cheers,
Nicholas
next prev parent reply other threads:[~2003-05-28 22:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-28 22:01 David Carlton
2003-05-28 22:06 ` Daniel Jacobowitz
2003-05-28 22:51 ` Nicholas Wourms [this message]
2003-05-28 23:59 ` DJ Delorie
2003-05-29 20:37 ` amodra
2003-05-30 5:37 ` unsubsribe Gitesh Kulkarni
2003-05-29 13:51 ` parallel builds failing in bfd H. J. Lu
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=3ED53CC0.9040305@myrealbox.com \
--to=nwourms@myrealbox.com \
--cc=binutils@sources.redhat.com \
--cc=drow@mvista.com \
--cc=gdb@sources.redhat.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).