[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: building directly from $(top_builddir)
From: |
Ralf Wildenhues |
Subject: |
Re: building directly from $(top_builddir) |
Date: |
Wed, 22 Jul 2009 22:38:23 +0200 |
User-agent: |
Mutt/1.5.20 (2009-06-15) |
Hello Akim,
* Akim Demaille wrote on Wed, Jul 22, 2009 at 05:52:16PM CEST:
>
> Of course there are several problems. The one that annoys me the
> most is the total lack of scoping in Makefiles, which becomes a
> real problem when you want to play with various sets of *FLAGS.
> So I use foo_CPPFLAGS, which, unfortunately causes Automake to
> create adhoc rules for every single file, which results in
> possibly extremely large Makefiles which Make takes quite long to
> load...
>
> I wish Automake had a "I *will* use GNU Make on the other side"
> option. Something that would help keeping the Makefiles smaller.
As in:
# Caution! The following
# - subverts automake's renaming of targets with per-target features,
# - relies on the specific names of object files (an undocumented
# internal automake detail), namely absense of per-target flags
# and existence of inference rules for these objects,
# - requires GNU make.
# Do not use this technique for anything automake should detect.
# Do expect this to break with Automake 1.X+1.
AUTOMAKE_OPTIONS = -Wno-portability
foo.$(OBJEXT): AM_CPPFLAGS = -Dobject_specific=1
bar.$(OBJEXT): AM_CFLAGS += -O0
$(baz_OBJECTS): AM_CXXFLAGS += ...
?
Because if you use per-target flags, then there is not much Automake can
do if it is to keep up the renaming scheme: it has to output per-object
rules. And these only factor so far.
Cheers,
Ralf
PS: Bug reports against Automake from newbies using the above will be
forwarded to you. :-)
PPS: For extremely large makefiles, somebody should write an efficient
sparse+wildcard matrix transpose (sparse dag reversal if you like one
made-up term better than the other) and a portable parallel inotifyd to
feed makefiles into a parallel Beta build system with suitable feature
set to match/map that part of GNU make functionality that doesn't depend
on dag traversal order (and maybe also the other part); see this thread:
<http://thread.gmane.org/gmane.comp.gnu.make.general/7667/focus=7701>.
- Re: Help with create_pipe_bidi, Eric Blake, 2009/07/18
- new module pipe-filter, Bruno Haible, 2009/07/19
- Re: new module pipe-filter, Bruce Korb, 2009/07/21
- Re: new module pipe-filter, Paolo Bonzini, 2009/07/21
- Re: new module pipe-filter, Bruno Haible, 2009/07/21
- Re: new module pipe-filter, Paolo Bonzini, 2009/07/21
- Re: new module pipe-filter, Paolo Bonzini, 2009/07/22
- Re: new module pipe-filter, Bruce Korb, 2009/07/31