This is the mail archive of the
mailing list for the Cygwin project.
Re: New Cygwin Net Release (make error)
I think that this problem is localized to the cygwin version of
make with its patches for handling win32 paths. I've notified
the cygwin make "maintainer" about this.
On Wed, Apr 19, 2000 at 12:56:47PM -0400, Paul D. Smith wrote:
>%% "Christopher Jones" <email@example.com> writes:
>HTML isn't necessary on the mailing list; plain text is just fine, thanks.
> >> From Bernard
> >> From Brian
> >>> #--begin Makefile---
> >>> SOMEVAR=$(ANOTHERVAR)/etc
> >>> include $(DEVDIR)/Makefile.mstr
> >>> #--end Makefile---
> >>> DEVDIR is defined in the environment. ANOTHERVAR however is
> >>> defined in the included makefile. I thought make was supposed to
> >>> try to do full expansion on a second read of the makefile? Seems
> >>> to have worked before.
> >> In fact make is suppose to expand SOMEVAR only when it sees
> >> $(SOMEVAR), so yo u only have to be sure that ANOTHERVAR is set
> >> before trying to use SOMEVAR.
> >> However be careful: if SOMEVAR is used in a dependency (either
> >> target or dependant part), it will be expanded as soon as it is
> >> seen.
>This is true, but not relevant to this situation. A recursive variable
>like SOMEVAR is expanded again _every_ time it's seen, not just the first
>time. So even if it's been expanded before, that won't be a problem
> cj> So I went off and tried to duplicate my problem with the smallest
> cj> Makefile possible and have succeeded. Turns out the problem is
> cj> with a target macro's value indicating a dos style filename,
> cj> e.g. e:/dir/file (yes, with UNIX slashes) even with MAKE_MODE=UNIX
> cj> set in the environment. Using something like //e/dir/file works
> cj> of course. I think that on win32 e:/dir/file is supposed to be
> cj> allowed without confusing the make parser but I cannot find much
> cj> in the info documentation to help make this clearer (it did work
> cj> in the past with make 3.75, the cygwin 1.1 net release uses 3.77).
>It would be nice if you'd included the "smallest Makefile possible", as
>well as the error you got and what you expected it to do :).
>>From the description above I'm pretty lost as to what the problem you're
>seeing actually is.
> Paul D. Smith <firstname.lastname@example.org> Find some GNU make tips at:
> http://www.gnu.org http://www.ultranet.com/~pauld/gmake/
> "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
>Want to unsubscribe from this list?
>Send a message to email@example.com
firstname.lastname@example.org Cygnus Solutions, a Red Hat company
Want to unsubscribe from this list?
Send a message to email@example.com