[Top][All Lists]

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

RE: removing compile directive

From: Dave Korn
Subject: RE: removing compile directive
Date: Wed, 23 Apr 2008 19:00:02 +0100

address@hidden wrote on :

> Paul Smith wrote:
>> On Mon, 2008-04-21 at 10:43 -0700, Brian Dessent wrote:
>>> CFLAGS = $(filter-out -D_REMOVE_THIS_,$(CFLAGS))
>> You can't do this: recursive variables cannot reference themselves.
> I'm actually curious whether this is considered as a feature or a
> limitation, or maybe just tradition with GNU make?

  It's a limitation in the nature of the universe: the universe is finite, and
therefore the entropic limits on computability that follow from its finite
nature mean we can never run an infinite loop to recursion.
> I mean, basically it is very clear what the writer of above line
> has in mind, so the program could as well support it.

  I assume the "very clear" intention that you perceive the writer to have had
in mind is this:

CFLAGS := $(filter-out -D_REMOVE_THIS_,$(CFLAGS))

i.e. a non-recursive operation; and that you are suggesting that make could
overlook the fact that what they actually wrote was an operation that recurses
infinitely because it has no termination condition.

  But wait.

  Because you're wrong.  That's *not* what the author intended at all.  To
another point-of-view, it might seem equally "very clear" that what the author
intended to write was

CFLAGS = $(filter-out -D_REMOVE_THIS_,$(CXXFLAGS))

or maybe

CFLAGS = $(filter-out -D_REMOVE_THIS_,$(DFLAGS))

  DFLAGS, of course, is the variable they use to store common -D options used
in both C++ and C compilations.  You couldn't be expected to have known this -
and neither could make.  

  That is why, in the general case, it is a bad idea for an interpreter to try
and second-guess what the user "really meant".  By emitting an error, the
author's attention is drawn to the fact that their code is invalid, and they
can fix it; if make were to just take a guess, it might lead to any kind of
bizarre errors cropping up silently later on in the build process, and would
be very very very much harder to track down to the original mistake.

Can't think of a witty .sigline today....

reply via email to

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