Re: How to capture a set of recurring rules?

[Peng Yu]

On Thu, Feb 4, 2010 at 11:34 PM, Paul Smith <address@hidden> wrote:
> On Tue, 2010-02-02 at 07:58 -0600, Peng Yu wrote:
>> That is because I want to keep everything related to a RData file
>> close to each other. Otherwise, I have changed multiple distant places
>> in a Makefile. When the number of RData is larger, it will be a
>> nightmare to maintain the makefile.
>
> Most experienced makefile authors will agree, I expect, that the Best
> Practice way to write a complex makefile environment is to use the
> variable assignment method.
>
> That is, every makefile doesn't do anything but assign to variables.  No
> rules are written at all.
>
> So a makefile might look something like:
>
>        PROGRAMS += myprog
>
>        myprog_SRCS = myprog.c myio.c myprint.c
>        myprog_CPPFLAGS = -I$(topdir)/include
>        myprog_LIBS = -lm
>
> etc.  This is all simple, straightforward, and easy to understand.  Any
> developer and create and maintain these files.  Obviously, depending on
> your situation, you might have to be more complicated than this.
>
>
> Then you have your makefile guru create a set of "framework" makefiles
> that use the variable values, plus some advanced make techniques that
> include recursive variable definitions, $(eval) and $(call), and others,
> and instantiate rules to allow all the work to happen.  This is deep
> magic, often, but that's OK because only the magicians need to
> understand it.  Use include or special wrapper scripts or whatever to
> get the framework makefiles into make.

Essentially, what you are saying is to create an embedded language in
GNU make to make it more powerful. Since this embedded language is not
supported natively by GNU make, will the code written in this embedded
language be difficult to debugging?

A similar situation arises in C++ template metaprogramming. Although
you can do a lot of complex things in template, but it makes the
debugging process more difficult unless there are appropriate
debugging tools.

Considering these things, I think that a better route in the long run
may be to consider what is features are essential and add the features
along with the debugging facilities.