Re: How to capture a set of recurring rules?

[Peng Yu]

On Thu, Feb 4, 2010 at 7:29 PM, Philip Guenther <address@hidden> wrote:
> 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".)

I meant "should have to".

>> 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?

I believe what you mentioned is essentially a migration problem, which
is common in many other languages. Python 3 is not backward compatible
with Python 2.x. GCC 4.x.x may not be fully compatible with GCC 3.x.x.
But if there is feature that make the languages better, these two
languages choose to integrate or evolve. I think that GNU make should
take a similar philosophy rather than worrying too much about backward
compatibility.

> 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.

I have no idea how 'ant', 'scons' or 'cmake' are different between
themselves and from GNU Make. What "embedded" language you referred to
in these cases? Can they be used in the case wherever GNU Make is
appropriate?