help-make
[Top][All Lists]
Advanced

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

Re: why does make strip / at the end of a directory prerequisite??


From: Lane Schwartz
Subject: Re: why does make strip / at the end of a directory prerequisite??
Date: Thu, 8 Sep 2011 09:51:24 -0400

On Thu, Sep 8, 2011 at 9:12 AM, Mark Galeck (CW) <address@hidden> wrote:
> I agree:
>
>>On Unix-like systems which use / as the file path separator, the two
> items you describe ("dir" and "dir/") are treated as exactly the same
> item.
>
>
>>I may be wrong on this, but I believe that "/" is not allowed as part
> of a file name on Linux.
>
> I think you are contradicting what you said before.

No, I'm not contradicting what I said. There are two different
concepts in play here: a file name and a directory path.

The value "dir" is a file name. It could also be a relative directory path.

The value "dir/" is a relative directory path. It is NOT a file name.

The value "/" on Unix-like systems is the directory path separator
character. AFAIK, it is disallowed as part of file names.




> And I disagree with this.  Let me prove it, by showing what I just learned 
> from Philip and Paul:
>
> address@hidden: ls dir/
> foobar
>
>
> My question was not "what to change to make it work".  I know the answer to 
> that.   My question was "why doesn't this work, is it a bug or am not 
> understanding something".


This is not a bug. This is an artifact of directory path and file name
resolution in action. Let's take a look at what's happening:


%/:
       mkdir -p $@

dir/foobar: dir/
       touch $@


> GNU Make on Linux thinks that dir is the prerequisite, not dir/, and bombs.
> Is this a bug??

The prerequisite of the second rule is "dir/" - make takes this value
and resolves the path and file name. The file name resolves to "dir"
(remember "/" is the path separator, not part of the file name). This
is the correct and intended behavior.



> So this is just "syntactic sugar" for me.  I use syntactic sugar all the 
> time.  In this case, I found out that I could put more sugar to make it work:

%/.:
       mkdir -p $@


This fix is not syntactic sugar. It's a substantive change to what
you're talking about. Because "/" can't be part of a file name, the
pattern "%/" is exactly equivalent to the pattern "%". So this pattern
matches absolutely any file name. The second pattern "%/." says to
match the file called "." that is in any directory. So this rule will
match the "." file within any directory.

I assume that your overall goal is to have a single rule that can be
used to create directories, but won't fire for non-directory files. If
so, then you should be able to accomplish that goal by using your fix,
then specifying "x/." as the prerequisite in each rule that needs a
directory "x" to exist:

%/.:
       mkdir -p $@

dir/foobar: dir/.
       touch $@

Notice the change to the second rule. Instead of specifying "dir/" as
the prerequisite, I've specified "dir/." which will match the pattern
rule "%/." This will result in "mkdir -p dir/." which will serve to
create the directory "dir"

Hope this helps!

Cheers,
Lane



reply via email to

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