[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Recompiling all sources when the makefile changes

From: Nick Bowler
Subject: Re: Recompiling all sources when the makefile changes
Date: Thu, 9 Oct 2014 15:33:18 -0400
User-agent: Mutt/1.5.22 (2013-10-16)

On 2014-10-09 20:07 +0100, R. Diez wrote:
> > If "configure" is changing something, an easy and reliable option is
> > to ensure that it changes config.h (or some other configuration
> > header), which will naturally cause a rebuild of files that include
> > the header.
> This is not as straightforward as it sounds. My project currently does
> not even have a config.h file, and even if it had one, there is no
> reliable way to make sure that all sources end up including that file.

Changing an existing project to use AC_CONFIG_HEADERS when it does not
currently do so is a pretty big change, yeah, because you must include
config.h in every source file.

It's something you might want to look into anyway, as it can avoid
problems with DEFS exceeding command-line length limits.

> It may also be a different compiler flag that has no effect on the
> config.h file whatsoever. It is safer if all the object files depend
> on the makefile.

While it's your project and you can do this if you want, making
all objects depend on the makefile sounds like a really silly idea.
Nobody wants to spend 30 minutes recompiling because they added one
source file to a library, or because they added an additional test

I suggest choosing some specific features to test, and make things depend
on THAT.  For example, you could rebuild if CFLAGS are changed by storing
the previous setting of CFLAGS in a file, update that file if the current
setting differs, then add prerequisites on THAT file.

> > It's not documented in the manual, but there are automake variables
> > that can help you add prerequisites to your object files.  They have
> > the form mumble_OBJECTS and contain the list of object files for a
> > particular program or library, corresponding to mumble_SOURCES.
> Thanks, that looks promising, I'll give it a go.
> The fact that is not documented makes me worry that it may change in
> the future without further notice.

Sure, always something to consider before using undocumented functionality.
For what it's worth, I use mumble_OBJECTS to add extra prerequisites to
objects.  It's too convenient to pass up.

> > The object filenames are reliable as long as you don't change any
> > settings (like subdir-objects, but also other things).  So it is
> > safer to use mumble_OBJECTS in my opinion.
> I am not sure what you mean here. Do you mean that, if I turn on
> subdir-objects or some other option, then mumble_OBJECTS may not work
> any more?

No, mumble_OBJECTS will work correctly regardless of the actual object
names, which is why I suggested it is safer than specifying object
filenames directly.

If you wrote some object filename explicitly in your, it may
be out of date if you, for example, added per-target CFLAGS or enabled

Nick Bowler, Elliptic Technologies (

reply via email to

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