[bug #17230] Leading ./ is stripped from targets and prerequisites

[anonymous]

Follow-up Comment #1, bug #17230 (project make):

bug #10708
bug #15338

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

[bug #17230] Leading ./ is stripped from targets and prerequisites

[anonymous]

URL:
  

 Summary: Leading ./ is stripped from targets and
prerequisites
 Project: make
Submitted by: None
Submitted on: Saturday 07/29/2006 at 00:59 UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
   Component Version: 3.79.1
Operating System: Any
   Fixed Release: None

___

Details:

Below is a stripped-down version of a much more complicated makefile.

Several %.r files are targets. Each %.r goes into one directory called
$(RES_DIR), and depends on a %.exe of the same name in another
directory, called $(EXE_DIR).

The %.exe are intermediate targets. Normally they are generated by
compiling, and have a pattern as a prerequisite too, but for these
purposes, no prerequisite is necessary, and we'll just create a shell
script executable.

The problem: If the %.exe files are explicitly listed as coming from
./ (the working directory), the ./ is stripped from the targets and
prerequisites.

That is, if $(EXE_DIR) is . then $(EXE_DIR)/ is not left intact in
$@ and $<.

This occurs in three contexts in which the ./%.exe pattern is used
below: When the ./%.exe is a target, when the ./%.exe is a
prerequisite, and when the pattern is used to declare the %.exe
targets as immediate:

# make
$(EXES) = ./a.exe ./b.exe  GOOD
echo "echo I hope . is in your path" > a.exe   Should be ./a.exe
chmod a+x a.exeShould be ./a.exe
a.exe  Should be ./a.exe
I hope . is in your path
$(EXES) = ./a.exe ./b.exe  GOOD
echo "echo I hope . is in your path" > b.exe   Should be ./b.exe
chmod a+x b.exeShould be ./b.exe
b.exe  Should be ./b.exe
I hope . is in your path
rm a.exe b.exe Consistent

If . is not in your PATH, then this error occurs:

# make
$(EXES) = ./a.exe ./b.exe
echo "echo I hope . is in your path" > a.exe
chmod a+x a.exe
a.exe  Should be ./a.exe - FATAL
make: a.exe: Command not found
make: *** [results/a.r] Error 127
rm a.exe

The problem is the same whether ordinary rules, pattern rules, or
static rules are used.

There are workarounds, such as adding . to your PATH (insecure!),
explictly using ./$< instead of $< (won't work if EXE_DIR is changed
to an absolute path), etc. But none of these should be necessary,
because the explicit ./%.exe pattern should have remained intact.

For the purposes of comparing whether two targets or prerequisites
are the same name, leading ./'s should be ignored. But leading ./'s
should be kept intact in automatic variable expansions such as $<
and [EMAIL PROTECTED]

(Bugs 10708 and 15338 are the same thing. This is just another example
showing how it can fatally ruin a project -- a make "project", that is.)







___

File Attachments:


---
Date: Saturday 07/29/2006 at 00:59 UTC  Name: Makefile  Size: 401B   By: None
Makefile


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: 3.81 and windows paths

[Paul D. Smith]

%% "John W. Eaton" <[EMAIL PROTECTED]> writes:

  jwe> On 28-Jul-2006, Paul D. Smith wrote:
  | This would be very tricky: right now all the code to do DOS vs. POSIX
  | pathnames is controlled through #ifdefs, so it's a compile-time thing.
  | Changing it to a runtime thing would be a lot of work, I think... the

  jwe> OK, but I still think it should be implemented as an optional
  jwe> feature that users can select unless we can prove that the
  jwe> feature doesn't cause trouble for valid Makefiles that use only
  jwe> Posix filenames.

As I said, we can definitely say it could cause trouble, but in pretty
rare situations (I believe).

Whether that's enough to cause Cygwin to reject this option is,
ultimately, up to them.

Note I'm not even thinking about making this feature available on
non-Windows systems as that just doesn't make sense.

  | #ifdeffing in GNU make is kind of a mess, with all the different ports
  | we support.

  jwe> Yes, that's unfortunate.  I don't think that it is necessary to
  jwe> use an intricate mess of #ifdefs all throughout a program to
  jwe> achieve portability to a wide variety of systems.  That seems to
  jwe> be a design decision that was made fairly early on in the
  jwe> development of Make (long before you became the maintainer, I
  jwe> would guess).

Yes, it's too bad.  Supporting wildly different host platforms can be
done much more cleanly BUT you need to do a lot of up-front work and put
a lot of thought into it.  Or, you can have something similar to
Apache's APR library or whatever available to you.

Obviously the GNU make ports weren't handled that way, for quite
reasonable reasons.  Even so there's a lot of room to clean this up now,
but not a lot of incentive I suppose.

I asked on some Amiga mailing lists whether that port was still used and
useful; if it wasn't I was going to rip it out which would have helped
a good bit.  But, by gosh, some people actually still do use it!


The next version of GNU make will require an ISO 1989 C compiler and
runtime library and give up supporting pre-standard K&R compilers.  That
will help a tiny little bit.

-- 
---
 Paul D. Smith <[EMAIL PROTECTED]>  Find some GNU make tips at:
 http://www.gnu.org  http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: 3.81 and windows paths

[Paul D. Smith]

%% Christopher Faylor <[EMAIL PROTECTED]> writes:

  >> Or is there something special going on that means this won't work?

  cf> I think this has been answered later in the thread, but the short answer
  cf> is - the MinGW make won't recognize the cygwin mount table or symlinks,
  cf> so you can't use cygwin paths in a MinGW makefile without resorting to
  cf> something like "cygpath".

Aha.  Gotcha.  Yes that would be a problem.

  >> Regardless, I still wonder whether my idea of building make for a POSIX
  >> environment with Cygwin, but setting HAVE_DOS_PATHS explicitly, would
  >> work.

  cf> I briefly thought that this might be a possibility but I've since
  cf> remembered cases where people complained about their linux
  cf> makefiles not working correctly due to the colon handling in 3.80.

Hm.  I just can't think of any but the most obscure cases where this is
true.  The DOS pathname handling in vanilla GNU make, as far as I know,
is very specific: if and ONLY if the first character of a pathname is a
letter and the second is a colon, then the path is considered a DOS
path.  The only constructs where the meaning is ambiguous would be very
rare; something like:

foo : c:bar

should this be interpreted as a static pattern rule:

foo : c : bar

or with the DOS path "c:bar"?  In this case it's obvious to us since the
latter leads to a syntax error but of course make doesn't know that when
it's parsing tokens.


Any ambiguity is trivially solved by adding whitespace before and/or
after the ":" in target rules.


To be clear: I'm certainly not suggesting that enabling HAVE_DOS_PATHS
will always behave correctly for any valid POSIX makefile, or even any
potentially valid Linux makefile.  However, it seems quite rare to run
into a conflict, so much so that I'm not sure it's worth worrying about.

I suppose there might be some backslash issues.  I really don't remember
what HAVE_DOS_PATHS does with backslashes in target/prerequisite
pathnames.


YM, of course, MV :-)

-- 
---
 Paul D. Smith <[EMAIL PROTECTED]>  Find some GNU make tips at:
 http://www.gnu.org  http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: 3.81 and windows paths

[John W. Eaton]

On 28-Jul-2006, Paul D. Smith wrote:

| This would be very tricky: right now all the code to do DOS vs. POSIX
| pathnames is controlled through #ifdefs, so it's a compile-time thing.
| Changing it to a runtime thing would be a lot of work, I think... the

OK, but I still think it should be implemented as an optional feature
that users can select unless we can prove that the feature doesn't
cause trouble for valid Makefiles that use only Posix filenames.

| #ifdeffing in GNU make is kind of a mess, with all the different ports
| we support.

Yes, that's unfortunate.  I don't think that it is necessary to use an
intricate mess of #ifdefs all throughout a program to achieve
portability to a wide variety of systems.  That seems to be a design
decision that was made fairly early on in the development of Make
(long before you became the maintainer, I would guess).

jwe


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: 3.81 and windows paths

[John W. Eaton]

On 28-Jul-2006, Chris Taylor wrote:

| So even if the DOS #ifdef was enabled, we'd be back at the point of 
| having patches to attempt to fix this behaviour.
| Unless there was some way of having two versions of make - one with this 
| behaviour and one without, controlled by /etc/alternatives perhaps?

Two versions for this seemingly small feature seems a bit much when a
command-line switch could do the job.

jwe


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: 3.81 and windows paths

[Chris Taylor]

Paul D. Smith wrote:

%% "John W. Eaton" <[EMAIL PROTECTED]> writes:

  jwe> On 28-Jul-2006, Paul D. Smith wrote:

  | Regardless, I still wonder whether my idea of building make for a POSIX
  | environment with Cygwin, but setting HAVE_DOS_PATHS explicitly, would
  | work.

  jwe> If this could cause some valid Makefiles to do the wrong thing as
  jwe> cgf suggests might happen,

Hm.  I don't think I saw that message?

Certainly there are obscure cases where enabling DOS path support will
behave differently, but they're pretty rare I believe.  Is this a Cygwin
thing?


This was a thing where POSIX compatible makefiles were not behaving as 
expected, which is now believed to be due to the cygwin dos-path 
handling patches.




  jwe> then can we at least make the behavior optional, perhaps with a
  jwe> command line option or magic target (maybe
  jwe> ".WINDOWS_FILENAMES:")?

This would be very tricky: right now all the code to do DOS vs. POSIX
pathnames is controlled through #ifdefs, so it's a compile-time thing.
Changing it to a runtime thing would be a lot of work, I think... the
#ifdeffing in GNU make is kind of a mess, with all the different ports
we support.

Honestly, I don't see a lot of benefit to it.  On a Windows system, even
in Cygwin, I would assume that everyone would always expect anything
that looked like a Windows pathname to be treated like a Windows
pathname.  We're not talking about enabling this support on UNIX, just
in Cygwin.



Well, the whole point of cygwin is to give a POSIX-compatible 
environment in win32. So it's aiming to be like linux, not windows.
This means that if something like a makefile parses fine in linux, but 
not in cygwin (barring linker stuff), something is wrong.


And so on from there..

So even if the DOS #ifdef was enabled, we'd be back at the point of 
having patches to attempt to fix this behaviour.
Unless there was some way of having two versions of make - one with this 
behaviour and one without, controlled by /etc/alternatives perhaps?


Speculation on my part anyway.


Chris / EqUaTe


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: 3.81 and windows paths

[John W. Eaton]

On 28-Jul-2006, Paul D. Smith wrote:

| Regardless, I still wonder whether my idea of building make for a POSIX
| environment with Cygwin, but setting HAVE_DOS_PATHS explicitly, would
| work.

If this could cause some valid Makefiles to do the wrong thing as cgf
suggests might happen, then can we at least make the behavior
optional, perhaps with a command line option or magic target (maybe
".WINDOWS_FILENAMES:")?  That way, people who don't ask for the
special feature won't be bitten by it.

Thanks,

jwe


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: 3.81 and windows paths

[mwoehlke]

Michael Eager wrote:

Christopher Faylor wrote:

On Thu, Jul 27, 2006 at 05:09:16PM -0400, Paul D. Smith wrote:

In fact, I'm wondering if there is an advantage to building GNU make
using the Cygwin environment, vs. using a native MingW (for example)
build of GNU make?  I'm afraid I'm woefully ignorant about the details.


There is no advantage using cygwin if you want to use a Makefile which
contains MS-DOS paths.  Using MinGW makes perfect sense in that case.
Despite having suggested this repeatedly, it seems some users are still
not clear on this concept.


When I ran into this problem, it was because there was a
WINDOWS environment symbol referenced in a dependency.
It's not practical to change the environment symbol -- it is
used by both makefiles and native windows programs.  Nor is it
practical to re-write the paths in the makefile -- because the
makefile needs to reference this (and other) shared environment symbols,
which are not fixed in the makefile.

There are two equally unpleasant resolutions recommended:
either install two products (Cygwin and MinGW) or retain
a back-level version of make, forgoing all future bug fixes.
Neither are very good, but I've opted for the second choice.


You're forgetting the third, correct choice: use cygpath to translate 
the offending environment variable (if you like, store a copy of the 
translated variable in make's environment).


--
Matthew
Warning: prolonged exposure to Cygwin may cause addiction.



___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: 3.81 and windows paths

[Christopher Faylor]

On Fri, Jul 28, 2006 at 09:56:20AM -0400, Paul D. Smith wrote:
>%% Christopher Faylor writes:
>cf> If you want to use a Makefile which works in a Cygwin environment,
>cf> however, then obviously you need to build it with a Cygwin gcc.
>
>You'll have to forgive my virtually complete ignorance of all things
>Windows, even Cygwin, but if you have a minute... why?
>
>I mean, if there is no special Cygwin code in make any longer, then
>can't people use a native Windows build of make and have it invoke tools
>in the Cygwin environment?
>
>Or is there something special going on that means this won't work?

I think this has been answered later in the thread, but the short answer
is - the MinGW make won't recognize the cygwin mount table or symlinks,
so you can't use cygwin paths in a MinGW makefile without resorting to
something like "cygpath".

>Regardless, I still wonder whether my idea of building make for a POSIX
>environment with Cygwin, but setting HAVE_DOS_PATHS explicitly, would
>work.

I briefly thought that this might be a possibility but I've since remembered
cases where people complained about their linux makefiles not working correctly
due to the colon handling in 3.80.  This may have been a side effect of the
ancient patches that I had been carrying forward but I have a feeling that
there are cases where a makefile which runs on linux could not be properly
parsed under cygwin.

I mentioned this here:

http://cygwin.com/ml/cygwin/2006-07/msg00896.html

>cf> Again, I'm sorry for any confusion this may have caused.
>
>Absolutely no problem Christopher; I hope I didn't sound peeved because
>I'm not.  I'm happy to see this change, and I'm happy that I understand
>the source of the confusion some Cygwin users have been having lately.
>It's all good!

No, I didn't detect any trace of "peevedness" at all.  I just hate when
decisions that I make have unintended consequences for other free
software volunteers.

cgf


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: 3.81 and windows paths

[Paul D. Smith]

%% "John W. Eaton" <[EMAIL PROTECTED]> writes:

  jwe> On 28-Jul-2006, Paul D. Smith wrote:

  | Regardless, I still wonder whether my idea of building make for a POSIX
  | environment with Cygwin, but setting HAVE_DOS_PATHS explicitly, would
  | work.

  jwe> If this could cause some valid Makefiles to do the wrong thing as
  jwe> cgf suggests might happen,

Hm.  I don't think I saw that message?

Certainly there are obscure cases where enabling DOS path support will
behave differently, but they're pretty rare I believe.  Is this a Cygwin
thing?

  jwe> then can we at least make the behavior optional, perhaps with a
  jwe> command line option or magic target (maybe
  jwe> ".WINDOWS_FILENAMES:")?

This would be very tricky: right now all the code to do DOS vs. POSIX
pathnames is controlled through #ifdefs, so it's a compile-time thing.
Changing it to a runtime thing would be a lot of work, I think... the
#ifdeffing in GNU make is kind of a mess, with all the different ports
we support.

Honestly, I don't see a lot of benefit to it.  On a Windows system, even
in Cygwin, I would assume that everyone would always expect anything
that looked like a Windows pathname to be treated like a Windows
pathname.  We're not talking about enabling this support on UNIX, just
in Cygwin.

-- 
---
 Paul D. Smith <[EMAIL PROTECTED]>  Find some GNU make tips at:
 http://www.gnu.org  http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: 3.81 and windows paths

[Paul D. Smith]

%% Christopher Faylor <[EMAIL PROTECTED]> writes:

  cf> There is no advantage using cygwin if you want to use a Makefile
  cf> which contains MS-DOS paths.  Using MinGW makes perfect sense in
  cf> that case.  Despite having suggested this repeatedly, it seems
  cf> some users are still not clear on this concept.

Well, I can understand the desire to use a generally POSIX environment,
but still have some requirements that it interact with native Windows in
some ways.  I did read the thread on the cygwin mailing list so I know
people could work around it with macros or cygpath or whatever.

  cf> If you want to use a Makefile which works in a Cygwin environment,
  cf> however, then obviously you need to build it with a Cygwin gcc.

You'll have to forgive my virtually complete ignorance of all things
Windows, even Cygwin, but if you have a minute... why?

I mean, if there is no special Cygwin code in make any longer, then
can't people use a native Windows build of make and have it invoke tools
in the Cygwin environment?

Or is there something special going on that means this won't work?


Regardless, I still wonder whether my idea of building make for a POSIX
environment with Cygwin, but setting HAVE_DOS_PATHS explicitly, would
work.

  cf> Again, I'm sorry for any confusion this may have caused.

Absolutely no problem Christopher; I hope I didn't sound peeved because
I'm not.  I'm happy to see this change, and I'm happy that I understand
the source of the confusion some Cygwin users have been having lately.
It's all good!


Cheers!

-- 
---
 Paul D. Smith <[EMAIL PROTECTED]>  Find some GNU make tips at:
 http://www.gnu.org  http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: 3.81 and windows paths

[Michael Eager]

Christopher Faylor wrote:

On Thu, Jul 27, 2006 at 05:09:16PM -0400, Paul D. Smith wrote:

In fact, I'm wondering if there is an advantage to building GNU make
using the Cygwin environment, vs. using a native MingW (for example)
build of GNU make?  I'm afraid I'm woefully ignorant about the details.


There is no advantage using cygwin if you want to use a Makefile which
contains MS-DOS paths.  Using MinGW makes perfect sense in that case.
Despite having suggested this repeatedly, it seems some users are still
not clear on this concept.


When I ran into this problem, it was because there was a
WINDOWS environment symbol referenced in a dependency.
It's not practical to change the environment symbol -- it is
used by both makefiles and native windows programs.  Nor is it
practical to re-write the paths in the makefile -- because the
makefile needs to reference this (and other) shared environment symbols,
which are not fixed in the makefile.

There are two equally unpleasant resolutions recommended:
either install two products (Cygwin and MinGW) or retain
a back-level version of make, forgoing all future bug fixes.
Neither are very good, but I've opted for the second choice.

It seems to me that it should be possible to have the
DOS path within quotes, so that it doesn't trigger make's
pattern matching syntax.  That would be a more acceptable
solution than the other two.

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: 3.81 and windows paths

[Christopher Faylor]

On Thu, Jul 27, 2006 at 05:09:16PM -0400, Paul D. Smith wrote:
>In fact, I'm wondering if there is an advantage to building GNU make
>using the Cygwin environment, vs. using a native MingW (for example)
>build of GNU make?  I'm afraid I'm woefully ignorant about the details.

There is no advantage using cygwin if you want to use a Makefile which
contains MS-DOS paths.  Using MinGW makes perfect sense in that case.
Despite having suggested this repeatedly, it seems some users are still
not clear on this concept.

If you want to use a Makefile which works in a Cygwin environment,
however, then obviously you need to build it with a Cygwin gcc.

I'm *very* sorry that I didn't make it clearer in my release
announcement that the change in behavior for cygwin was due to a
decision on my part not to try to forward port some old make patches
which I have always found questionable.  Of course hardly anyone reads
release announcemnts, but that would mean that at least some people
wouldn't think of this as some sort of generic make bug.  It never
occurred to me that anyone would be complaining about this in the
bug-make mailing list.

Again, I'm sorry for any confusion this may have caused.

cgf


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

Re: 3.81 and windows paths

[Eli Zaretskii]

> Date: Thu, 27 Jul 2006 17:09:16 -0400
> From: "Paul D. Smith" <[EMAIL PROTECTED]>
> Cc: cygwin@cygwin.com, bug-make@gnu.org
> 
> I believe that this support is limited to handling drive letters without
> choking on the ":", actually: IIRC the native support still requires
> forward slashes (/) rather than backslashes (\).  I could be wrong
> though.

It is indeed safer to use forward slashes throughout in the native
Windows port, but backslashes are supported in most places in the
Makefile, in particular in rule's commands.


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make