This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: May g++ output windows-style paths instead of cygwin-style one?


On Tue, 16 Aug 2005, Angel Tsankov wrote:

> ----- Original Message -----
> From: "Angel Tsankov" <fn42551@XXX.XXX-XXXXX.XX>
> To: <cygwin@XXXXXX.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@XXXXXXX.XXX>
> > To: "cygwin mailing list" <cygwin@XXXXXX.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@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]