Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Tue, 16 Aug 2005 10:29:17 -0400 (EDT)
From: Igor Pechtchanski <pechtcha AT cs DOT nyu DOT edu>
Reply-To: cygwin AT cygwin DOT com
To: Angel Tsankov <fn42551 AT fmi DOT uni-sofia DOT bg>
cc: cygwin AT cygwin DOT com
Subject: Re: May g++ output windows-style paths instead of cygwin-style one?
In-Reply-To: <003101c5a247$fbfa26a0$cf34000a@sven>
Message-ID: <Pine.GSO.4.61.0508160943210.9560@slinky.cs.nyu.edu>
References: <000301c5a23d$04f46f00$cf34000a AT sven> <4301AB44 DOT 7DDCB59B AT dessent DOT net>  <000501c5a242$8a684e40$cf34000a AT sven> <003101c5a247$fbfa26a0$cf34000a AT sven>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 16 Aug 2005, Angel Tsankov wrote:

> ----- Original Message -----
> From: "Angel Tsankov" <fn42551 AT XXX DOT XXX-XXXXX DOT XX>
> To: <cygwin AT XXXXXX DOT XXX>
> Sent: Tuesday, August 16, 2005 12:11 PM
> Subject: Re: May g++ output windows-style paths instead of cygwin-style one?
>
> > ----- Original Message -----
> > From: "Brian Dessent" <brian AT XXXXXXX DOT XXX>
> > To: "cygwin mailing list" <cygwin AT XXXXXX DOT XXX>
> > Sent: Tuesday, August 16, 2005 12:00 PM
> > Subject: Re: May g++ output windows-style paths instead of cygwin-style one?

<http://cygwin.com/acronyms/#PCYMTNQREAIYR>.  Let's not feed the spammers.
Thanks.  Incidentally, what kind of mailer quotes full headers like this?

> > > Angel Tsankov wrote:
> > >
> > > > I have this problem, 'cause I use a windows build of make 3.81beta3
> > > > and it does not recognize cygwin style paths.
> > > > The latest cygwin build of make is 3.80, which has some bugs, and I
> > > > cannot use it.
> > >
> > > I think it would be more productive for you to get Cygwin make working
> > > than to try to jerry-rig a windows make into a posix environment. If
> > > you are running into a specific bug in the current packaged version that
> > > is fixed upstream, then you should document it here and the Cygwin
> > > package maintainer might release an updated package.
> >
> > Well, how do I document the bug?
>
> OK, here's something like a test case. Since a couple of my previous attempts
> to post a reply with a zip file attachment were unsuccessful, I've put the
> test case here:
> http://debian.fmi.uni-sofia.bg/~angel/test_case_make_3.80.zip

To summarize, for those who'd rather not download the full zip:

------------ BEGIN makefile ------------
GetAllFiles = \
$(eval AllFiles := $(wildcard $(addsuffix /*,$(strip $(1))))) \
$(AllFiles) \
$(if $(strip $(AllFiles)),$(call GetAllFiles,$(AllFiles)))

AllFiles := $(call GetAllFiles,Source)

all:
	@echo $(AllFiles)
------------- END makefile -------------

The "Source" directory contains 2 files, File1.h and File2.h.

> The result I get when running (the cygwin version of) make on my system is:
> Source/File1.h Source/File2.h h
>
> And the expected result is:
> Source/File1.h Source/File2.h

There are a bunch of things wrong with the code above (in particular, the
variable AllFiles is overridden), but it does look like a genuine make bug
(in the expansion of a $(call) function).  Adding some trace commands
shows that the function invocation itself produces the right result, and
the corruption happens on variable assignment (affected by the number of
whitespace in the assignment line).  Simply invoking "@echo $(call
GetAllFiles,Source)" as part of the "all" target produces the right
result.

As a temporary workaround, invoke GetAllFiles like this:

AllFiles := $(call GetAllFiles,Source makefile)

Using "recursively expanded" variables, e.g.,

AllFiles = $(call GetAllFiles,Source)

, also fixes the problem, but they aren't really a good solution for this.

> Result of running 'make --version':
> GNU Make 3.80
> [snip]
>
> It is a very strange problem.

Indeed.

> A couple of weeks ago I started a thread about the exact same problem on
> the make-w32 mailing list, assuming it had something to do with long
> file names. The thread is located here:
>
> http://lists.gnu.org/archive/html/make-w32/2005-07/msg00011.html

Not the same problem.  There, the output was corrupted, here, the variable
assignment has gone awry.

> As one can see, this problem has been fixed. Unfortunately, no newer
> version of make has been release so far, except for betas, the latest
> one being is 3.81beta3. The source code of the windows version of
> 3.81beta3 is available at ftp://alpha.gnu.org/gnu/make/

This particular problem must've been fixed by some other patch.
Nonetheless, now that the make maintainer is aware that there is a bug,
he'll likely look into releasing the updated version of make at some
point.  Since he's a volunteer (like the rest of us), he'll do it on his
own schedule (the bug is relatively minor, and there's a workaround, so
this probably won't happen soon).

HTH,
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha AT cs DOT nyu DOT edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor AT watson DOT ibm DOT com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/