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

[Angel Tsankov]

----- Original Message ----- 
From: "Igor Pechtchanski" <pechtcha@cs.nyu.edu>
To: "Angel Tsankov" <fn42551@fmi.uni-sofia.bg>
Cc: <cygwin@cygwin.com>
Sent: Thursday, August 18, 2005 6:05 PM
Subject: Re: May g++ output windows-style paths instead of 
cygwin-style one?


> On Thu, 18 Aug 2005, Angel Tsankov wrote:
>
>> > 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).
>>
>> Could you point out other wrong things with the code above so that 
>> I try
>> to avoid them in the future?
>
> Well, it's not as bad as it sounded -- it's a rather small bunch,
> actually.  :-)
>
> As I understand it, you're trying to implement a recursive directory
> search (akin to Ant's ** wildcard).  Try as I might, I couldn't come 
> up
> with a clearer way of doing this, so I guess what you have is ok. 
> My only
> gripe is that the AllFiles variable is going to be clobbered, so if 
> you
> have
>
> GetAllFiles = \
>  $(eval AllFiles := $(wildcard $(addsuffix /*,$(strip $(1))))) \
>  $(AllFiles) \
>  $(if $(strip $(AllFiles)),$(call GetAllFiles,$(AllFiles)))
>
> AllFiles := $(call GetAllFiles,Source)
> AllOtherFiles := $(call GetAllFiles,Includes)
>
> You will be surprised afterwards when looking at the value of
> $(AllFiles)...
>
> You could rewrite it as
>
> GetAllFiles = \
>  $(eval $(0)_123 := $(wildcard $(addsuffix /*,$(strip $(1))))) \
>  $($(0)_123) \
>  $(if $(strip $($(0)_123)),$(call GetAllFiles,$($(0)_123)))
>
> to avoid name clashes...
>
> BTW, the workaround I proposed (i.e., $(call GetAllFiles,Source 
> makefile))
> doesn't always work.

Unfortunately, you are right. I decided to use recursively expanded 
variables till next release despite my striving for efficiency.

>I think you may just have to find the right number
> of extra spaces in variable assignments...

Well, I could not find that number - it seemed to depend on the number 
of file names in the list and I did not investigate it any further so 
I'm not quite sure if this exactly was the case.


--
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/