bug-make
[Top][All Lists]
Advanced

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

Re: include should be relative to current Makefile


From: Ed H
Subject: Re: include should be relative to current Makefile
Date: Wed, 16 May 2012 10:49:10 -0700 (PDT)



From: Edward Welbourne <address@hidden>
To: Ed H <address@hidden>
Cc: address@hidden
Sent: Wednesday, May 16, 2012 1:21 AM
Subject: Re: include should be relative to current Makefile

> ifndef TOP
>
> include ../Makefile
>
> else
>
> SUBDIRS = <yadda yadda>
> TARGETS = <list of things>
> SRCS = <etc etc>
>
> endif
>
> All of the complexity you allude to can be safely buried in the TOP-level
> Makefiles,

I can't help but think this is an entirely upside-down approach.  You
appear to be expecting context's make-file to supply values for the SRCS
and SUBDIRS of the module, which should surely be the master source for
that information.  When sub-module foo is under separate version control
from the rest, this is particularly important: the source list may
change from one release of foo to the next - the parent shouldn't need
to care - that's *why* it includes a make fragment from the sub-module.

I should have been more clear,  I'm setting up the build so each user-specified
module Makefile (which lives in the same directory as the source for that module)
includes the parent's Makefile, specifies things to be built in that directory and
also specifies any sub-directories (which have their own Makefiles). Somewhere
at the TOP is the main project Makefile which includes a bunch of stuff for all
the rules and build options etc. This top-level Makefile also includes everything
going back down the tree following all of the module SUBDIRS, which are now
getting their TARGETS/SRCS etc. added into the dependency graph. My goal is
to have a single Makefile in each build directory which (as simply as possible)
specifies the what and not the how of building everything. "make" in any
sub-directory should behave just like a typical recursive make (building the
module and all sub-directories), while building any explicit target should also
build all dependencies of that target, even if they are in parent directories
(something typical recursive makes fail to do).

This is all inspired by/borrowing from https://github.com/aostruszka/nonrec-make/,
but without the symbolic links and separate Rules.mk files in each module directory.

  - Ed


reply via email to

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