bug-make
[Top][All Lists]
Advanced

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

RE: Checking application of dependencies from make rules without recipes


From: Martin Dorey
Subject: RE: Checking application of dependencies from make rules without recipes
Date: Wed, 21 Jun 2017 16:21:03 +0000

>> I don't see why it makes a difference in how rule types should be ordered

> A dependency graph is constructed by make scripts.

I don't think that's relevant: a graph's topology isn't dependent on the order 
in which its arcs are enumerated.

>> Only if an explicit rule does not exist will an implicit rule search
>> be performed.

> I got the impression that this general handling might need another look
> for one of my test cases.

When you submit a test case that demonstrates a bug, then I'm sure someone will 
look at it.

>> Makefiles are not like the shell or other interpreted languages where
>> commands are executed as they are parsed.

> They correspond to a special category of programming languages.
> I find that there are also functions supported which are
> immediately executed.

Expressions in some contexts are evaluated as make goes along, yes, as 
demonstrated by:

address@hidden:~/tmp/elfring-2017-06-21$ cat > Makefile
badger:
$(error stop here)
wombat:
address@hidden:~/tmp/elfring-2017-06-21$ make -p 2>&1 | grep wombat
address@hidden:~/tmp/elfring-2017-06-21$ make -p 2>&1 | grep badger
.DEFAULT_GOAL := badger
badger:
address@hidden:~/tmp/elfring-2017-06-21$

Expressions calculating prerequisites are a notable case, causing "variables 
before rules" to be one guideline for writing makefiles.  Those expressions 
aren't the "commands" of which Paul was speaking, which are in "recipes", part 
of "rules".  No-one claimed that makefiles were completely insensitive to 
order.  You claimed that the inability to cancel an explicit rule meant 
something important about whether explicit rules or implicit rules should come 
first.  Paul prompted you to explain what that was, but you haven't.


reply via email to

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