automake
[Top][All Lists]
Advanced

[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 10:12:57 -0400
User-agent: Mutt/1.5.22 (2013-10-16)

On 2014-10-09 14:53 +0100, R. Diez wrote:
[...]
> I noticed that, if I change the version number in the top-level
> configure.ac by amending the call to AC_INIT(), running "make" in the
> build directory automatically regenerates the 'configure' script and
> re-runs it. However, the C++ source files are not rebuilt, because
> everything is up to date. So it looks like the Autotools get the job
> only partially done.

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.

[...]
> I could try to make all object files depend on the makefile, which may
> not be completely accurate if the makefile includes other files, but
> it would probably be enough. However, I did not find a way to add an
> extra dependency to all .o files.

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.

So you can write something like:

  bin_PROGRAMS = mumble
  $(mumble_OBJECTS): extra-prerequisites

I don't think there is any automatically-defined variable that contains
ALL objects.

> I could try to manually guess the .o filenames from the .cpp
> filenames, but those .o filenames may change in the future,
> especially in the face of subdir-objects.

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.

Hope that helps,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)



reply via email to

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