[Swan-dev] missing make dependencies

Andrew Cagney andrew.cagney at gmail.com
Mon Aug 15 15:18:58 UTC 2016


On 12 August 2016 at 18:22, Antony Antony <antony at phenome.org> wrote:
> On Tue, Aug 09, 2016 at 08:51:02AM -0400, Andrew Cagney wrote:
>> On 8 August 2016 at 13:39, Antony Antony <antony at phenome.org> wrote:
>> > here is a report of missing make dependencies.
>> >
>> > Over the weekend I tracked down a couple missing make dependencies. Some of them are hard to trackdown when compiling over 9pfs or nfs...
>> >
>> > 1. addconn is missing dependency on lib/libipsecconf/keywords.c.   Seee below to reproduce.
>>
>> Thanks for the reproducer.
>>
>> > 2. make base or programs seems to miss dependency on Makefile.inc.local and possibly other Makefiles too?
>>
>> I'm not sure what you mean.
>
> Initially  Makefile.inc.local has two lines.

> cat Makefile.inc.local
> USE_LINUX_AUDIT=
> USE_FIPSCHECK=
> make base
> echo "DEBUG_CFLAGS=-g" >> Makefile.inc.local
> make base # does not seemes to re-make the programs with change to Makefile.inc.local

Yes.  If we play with Makefile.inc.local, then we get to decide if
"make distclean" is needed - sometimes it is some times it is not.
(Makefile.inc.local isn't required to build and test libreswan).

> And as excercise, if I try this.
> my git rep is clean; git diff is empty.
> echo  "#" >> Makefile
> make base still does not re-make.

It shouldn't.

As a guiding rule - the purpose of a Makefile is to describe the
dependency graph, not become an active participant in it (as an aside,
I recommend reading the "recursive make is bad" paper).

Admittedly we've some ugly hacks lurking in our code that contradict
this - where complex shell scripting forms part of a Makefile rule,
there might be an explicit dependency on that Makefile stub (makes
debugging the Makefile easier) - it is just lazyness, the complex
scripting should be moved to a file and then have the rule depend on
that.

> I think now pluto should be rebuild for two reasons.
> 1. Makefile has a newer timestamp.
> 2. git diff is not empty, this should update ./OBJ.linux.x86_64/lib/libswan/version.c which should cause re-building of pluto.
> May be version.c only used by pluto not other programms.

While having version.c re-generated because there is a new git commit
is nice, I've yet to find anything that implements this efficiently -
i.e., without having to assume and run git on every make invocation.

The compromise is to generate it once; and then assume that anyone
doing an official build is building from scratch.

> -antony


More information about the Swan-dev mailing list