help-make
[Top][All Lists]
Advanced

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

Re: How to capture a set of recurring rules?


From: Philip Guenther
Subject: Re: How to capture a set of recurring rules?
Date: Thu, 4 Feb 2010 17:29:46 -0800

On Tue, Feb 2, 2010 at 5:58 AM, Peng Yu <address@hidden> wrote:
> On Tue, Feb 2, 2010 at 1:13 AM, Philip Guenther <address@hidden> wrote:
...
>> Why do the dependencies need to be separate arguments to the macro and
>> not just one argument with embedded spaces?
>
> 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.

Sure, that's a reason for using $(eval) for this, but not a reason for
passing the dependencies as separate arguments.


> Actually, I don't think that you should ask this question,

(I think you meant to say "I don't think that you should _have_ to ask
this question".)


> as Means of Abstraction (according to SICP, http://mitpress.mit.edu/sicp/),
> with the closure property, which is a very important element in a
> programming language, is clearly not completely supported in GNU Make.
> Make should be able to build new rules from old rules. The rules
> should looks the same to user. Although the above solution practically
> works, it lacks the two ingredients.

"Welcome to the world of engineering."

One of the costs that an engineer has to balance against possible
gains is that of upgrading.  Given a choice between solving a problem
by delivering something that has minimal upgrade cost, but is
non-orthogonal, versus something that is orthogonal but requires that
everyone rewrite their existing code, which would you pick?  How about
when a competitor has already done the former?

Note that while GNU make does the former, other projects have chosen
the latter.  As a result, they're simply not versions of 'make'
anymore but rather completely different tools or systems.  If it's
more important to you that the languages you use following the rules
in SICP and less important that the tool be preinstalled everywhere or
support the Makefiles that you've already written, then you should
investigate the other tools that have been developed in this area,
such as 'ant', 'scons', or 'cmake', all of which (I believe) have much
more regular syntax and/or have better integration with their embedded
programming languages.


Philip Guenther




reply via email to

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