>________________________________
> From: Edward Welbourne <e...@opera.com>
>To: Ed H <e...@yahoo.com> 
>Cc: bug-make@gnu.org 
>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
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Reply via email to