mainmake - Support: sr #104345, Existence-only prerequisites

 
 

You are not allowed to post comments on this tracker with your current authentication level.

sr #104345: Existence-only prerequisites

Submitter:  None
Submitted:  Tue 21 Jun 2005 10:55:04 PM UTC
   
 
Category:  None Priority:  2
Severity:  1 - Wish Status:  Works For Me
Privacy:  Public Assigned to:  None
Originator Email:  -email is unavailable- Open/Closed:  Closed
Operating System:  None

Jump to the original submission

Sun 20 Sep 2009 09:00:45 PM UTC, comment #6: 

I haven't heard any response to this and as far as I can see the issue posted here is a bug that was fixed (although the request might have been for a new features indeed).

Paul D. Smith <psmith>
Group administrator
Tue 06 Sep 2005 09:58:41 PM UTC, comment #5: 

I think you might be running into a bug, and one that's already fixed at that.  Try using the latest version of GNU make (for example ftp://alpha.gnu.org/gnu/make/make-3.81beta3.tar.gz).  When I run your test I get the expected behavior: that case 1 and only case 1 results in the mkdir, and that only cases 1 and 2 result in the gcc command.  The timestamp of the bin target does not have any impact in any way on whether the bin/hello.out target is out of date or not.

Note that the way you described "existence-only" prerequisites sounds to me like you expect the compile to happen if the prerequisite was created.  The examples you give here leave out one case, which is of course impossible if you're creating a directory.  Suppose instead we have the following example:

   foo: | bar
   foo bar : ; touch $@

Now we can have these cases:

   case 1: neither foo nor bar exist
   case 2: foo exists, bar doesn't exist
   case 3: bar exists, foo doesn't exist
   case 4: both exist; foo is newer than bar
   case 5: both exist; bar is newer than foo
   case 6: both exist; they have an identical timestamp

If bar were a normal prerequisite, then foo will be touched in cases 1, 2, 3, and 5.  For order-only prerequisites, foo will be touched ONLY when foo doesn't exist, regardless of the state of bar (cases 1 and 3).

From the description of "existence only" prerequisites, it sounded like foo would be touched in cases 1 and 3, but also in case 2, where bar is created.  But maybe I'm wrong about the intent of the person making the request.

Paul D. Smith <psmith>
Group administrator
Tue 06 Sep 2005 09:27:44 PM UTC, comment #4: 

Consider the following simple makefile:


all : bin/hello.out

bin/%.out : %.c | bin
    gcc -o $@ $<

bin:
    mkdir bin


Note that "bin" is an order-only prerequisite for "bin/hello.out".  Consider the following four test cases:

Case 1:  Neither "bin" nor "bin/hello.out" exist.
Case 2:  "bin" exists but "bin/hello.out" does not exist.
Case 3:  Both exist, and "bin" is older than "bin/hello.out".
Case 4:  Both exist, and "bin" is newer than "bin/hello.out".

When make is given the makefile above, it can issue two commands, a mkdir command and a gcc command.  It issues the mkdir command for case 1 only.  It issues the gcc command for cases 1, 2, and 4.  This is exactly the same behavior as if "bin" were an ordinary prerequisite instead of an order-only prerequisite.

If "bin" were an existence-only prerequisite, I would expect the gcc command to be issued only for cases 1 and 2.

Perhaps this isn't the behavior you wanted for order-only prerequisites.  Perhaps you wanted them to behave the same as existence-only prerequisites.  Then Gnu Make's implementation of order-only prerequisites is flawed, and you can convert this feature request into a bug report.

Anonymous
Tue 09 Aug 2005 05:00:24 PM UTC, comment #3: 

I do agree with the first comment, though, that all the examples given seem to me to be good places for order-only prerequisites and I don't quite see the advantage in this new type of prerequisite.

Adding new basic capabilities like this is very tricky: you have to define how it will interact with all the other features of make: the existing order-only and normal prerequisites, things like double-colon rules, etc. etc.  Unless a really important and moderately common use case is given I'm not ready to expand GNU make syntax in this direction, especially when there are ways to do it already, even if those ways are slightly more round-about.

Paul D. Smith <psmith>
Group administrator
Sat 06 Aug 2005 01:23:50 PM UTC, comment #2: 

It's not clearly defined here, but as far as I can tell it means that "existence-only" prerequisites DO cause the target to be updated, if and only if the prerequisite didn't exist.  An order-only prerequisite will never cause the target to be out of date, regardless of whether it existed before or not.

Paul D. Smith <psmith>
Group administrator
Sat 06 Aug 2005 01:47:45 AM UTC, comment #1: 


> bin:
>    mkdir bin
>
> bin/foo: foo.o ! bin
>    gcc -o bin/foo foo.o
>
> This means: before building bin/foo, the directory bin must
> exist. The modification time of bin does not matter.


Why aren't order-only prerequisites sufficient for this? That's what I'm using for this case and they seem to work fine.

Anonymous
Tue 21 Jun 2005 10:55:04 PM UTC, original submission:  

Currently, GNU Make has two types of prerequisites:  "normal" prerequisites and "order-only" prerequisites.  I propose to add a third type, "existence-only" prerequisites.  A target with an existence-only prerequisite would only be considered out of date if the prerequisite didn't exist; the relative dates would not matter.  For example, suppose you chose the symbol '!'  exclamation point) to indicate existence-only prerequisites in the same way that '|' (pipe) indicates order-only prerequisites.  The following is an example of where this would be useful (this is just a makefile fragment):

bin:
    mkdir bin

bin/foo: foo.o ! bin
    gcc -o bin/foo foo.o

This means:  before building bin/foo, the directory bin must exist.
The modification time of bin does not matter.

Another example of where this would be useful (again, just a fragment):

inc/bar.h:
    ln -s ../srcdir1/bar.h inc/bar.h

inc/bleep.h:
    ln -s ../srcdir2/bleep.h inc/bleep.h

incs:=inc/bar.h inc/bleep.h

foo.d: foo.c ! $(incs)
    gcc -M -Iinc $< >$@

This means:  before generating header file dependencies, symlinks to the various header files should be made in the inc directory.

Neither of these examples would work properly if the prerequisites were normal rather than existence-only.  I know that it's possible to do the same thing using "wildcard" and "filter-out", but that's a lot messier, and is much harder to read.  I think this capability is useful enough that it should be supported directly as a new type of prerequisite.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by psmith (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-09-20 psmith Open/ClosedOpen Closed
        StatusNone Works For Me
    2005-08-09 psmith Carbon-Copy- Added -email is unavailable-
    2005-08-06 psmith Priority5 - Normal 2
        Severity3 - Normal 1 - Wish

    Back to the top

    Powered by Savane 3.13-bb6a.
    Corresponding source code