Mail Archives: cygwin/2005/08/18/15:19:37
On Thu, 18 Aug 2005, Angel Tsankov wrote:
> ----- Original Message -----
> From: "Igor Pechtchanski" <pechtcha AT XX DOT XXX DOT XXX>
> To: "Angel Tsankov" <fn42551 AT XXX DOT XXX-XXXXX DOT XX>
> Cc: <cygwin AT XXXXXX DOT XXX>
Umm, again, <http://cygwin.com/acronyms/#PCYMTNQREAIYR>...
> > On Thu, 18 Aug 2005, Angel Tsankov wrote:
> >
> > > > 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).
> > >
> > > 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.
Another thing you could try is run the final result of $(call
GetAllFiles,...) through $(wildcard ...) -- all non-existent files will be
eliminated. Inefficient, I know, but safe.
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/
- Raw text -