Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Message-ID: <000301c5a423$22b89560$cf34000a@sven> From: "Angel Tsankov" To: Cc: References: <000301c5a23d$04f46f00$cf34000a@sven> <4301AB44.7DDCB59B@dessent.net> <000501c5a242$8a684e40$cf34000a@sven> <003101c5a247$fbfa26a0$cf34000a@sven> <000301c5a3e3$10154420$cf34000a@sven> Subject: Re: May g++ output windows-style paths instead of cygwin-style one? Date: Thu, 18 Aug 2005 21:32:03 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-IsSubscribed: yes ----- Original Message ----- From: "Igor Pechtchanski" To: "Angel Tsankov" Cc: 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" >> > > To: >> > > 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" >> > > > To: "cygwin mailing list" >> > > > Sent: Tuesday, August 16, 2005 12:00 PM >> > > > Subject: Re: May g++ output windows-style paths instead of > >> > > cygwin-style one? >> > >> > . 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/