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


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:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]