[Top][All Lists]

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

Re: non recursive includes proof of concept #2

From: Robert Collins
Subject: Re: non recursive includes proof of concept #2
Date: Sat, 20 Dec 2003 14:50:54 +1100

On Sat, 2003-12-20 at 00:41, Alexandre Duret-Lutz wrote:
> >>> "Robert" == Robert Collins <address@hidden> writes:
> [...]
>  Robert> It transforms macros and paths in an included file (called
>  Robert> Makefile.rules for now) , to make them suitable for a non-recursive
>  Robert> build.
> I'm skeptical about whether this approach can be made to work
> intuitively.  More precisely I don't think it is generally
> possible to let users write a subdir fragment as if
> it would be run locally in the subdirectory, and translate
> *anything* so it actually works from another directory.  Let's
> mention user-defined rules referring rewritten variables, or
> flag variables including things such as -I.

Right. To have both in-dir and top-level Makefiles work may not be
possible. My key goal is the top level Makefile assembled from the
included fragments though - if the dual approach won't work.. it won't.
That said, if the user can do it with only minor hoops to jump

> Anyway you asked for comments on the patch so here are some.
> (I'm sorry I had to be brief in the end, because I have a train
> to catch in one hour.  I'll be away for one week.)
> I don't see what in your changes require the file to be named
> Makefile.rules.

It isn't required to be named that now - my original proof of concept 2
odd years ago started out with a fixed name, which I removed even before
posting back then. So - no requirement.

> This sounds neat.  But AFAICT no test case really cd into that
> given dir and perform the build.

I'll add a test case.

> [...]

> Judging from the comments, I understand that 
> bin_PROGRAMS = foo does not become path/foo?
> Or is it a typo in the example of @canonised_macro_lists?

ah. It's 
bin_PROGRAMS = foo
foo_SOURCES = bar.c
bin_PROGRAMS = path/foo
path_foo_SOURCES = path/bar.c

> Since these variables will be used for member ship check, better
> use a hash

Ok, will try this out.

> Is this required?  `include' automatically distributes it's
> argument, I presume you've preserved this for `subdir_include'.

Right, so it won't be required.

> Please use GNU-like 2-space indentation for new code (see HACKING).
> The tail of all Perl files already setups the indentation style
> for Emacs.  Maybe you can submit similar hints for your editor.

Hmm, I thought I had.

I'll stop replying here - I'm going to implement your suggestions as I
get time.

(an aside: some of the issues are holdovers from the 2 year old patch
I'd resurrected).

I'll drop a note here when I've done your suggestions.


GPG key available at: <>.

reply via email to

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