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.