[Top][All Lists]
[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