On Wed, May 16, 2012 at 1:49 PM, Ed H wrote:
> 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.
Old thread, I know, and I have no time to contribute to the discussion
of "i
>
> From: Edward Welbourne
>To: Ed H
>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
>>
&
> ifndef TOP
>
> include ../Makefile
>
> else
>
> SUBDIRS =
> TARGETS =
> SRCS =
>
> 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
>
>By the same logic, one can use a (module-specific) variable meaning
>"here" in each sub-directory's make-file fragments; so foo/config.mk
>refers to its source files as $(FOOSRC)/bar.c and so on, rather than
>assuming FOOSRC=. (although that likely remains th
> I think changing gmake's behavior to match cpp's will eliminate the
> need for a lot of hacky farting around to get non-recursive systems
> working smoothly.
I can sympathise. The present behaviour effectively requires one to cd
to (or pass a -C for) the directory of a make file in order to
I've been trying to put together a non-recursive build system and ran into
the fact that gmake's "include" directive is always relative to the CWD.
This isn't how cpp does things, and is unexpected behavior to say the least.
Is there some unavoidable reason why relative includes aren't relative to
