From: Chris S. <ir0...@gm...> - 2006-09-10 14:40:22
|
Hey All, I just tried to compile w32api for MinGW and found that it's now throwing all the header files in include/w32api. It's coming from lib/Makefile.in: ifneq (,$(findstring cygwin,$(target_alias))) inst_includedir:=$(tooldir)/include/w32api inst_libdir:=$(tooldir)/lib/w32api else ifneq (,$with_cross_host) inst_includedir:=$(tooldir)/include/w32api inst_libdir:=$(tooldir)/lib else inst_includedir:=$(includedir) inst_libdir:=$(libdir) endif endif It seems that the $with_cross_host is catching the MinGW based compile as well. Do I add a rule explicitly for MinGW: ifneq (,$(findstring mingw,$(target_alias))) inst_includedir:=$(includedir) inst_libdir:=$(libdir) else Though that seems to defeat the purpose of the file 'else'. I'd appreciate some help here, given that autotools are really not my strong suit. Thanx! Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org |
From: Keith M. <kei...@us...> - 2006-09-10 16:30:54
|
On Sunday 10 September 2006 3:40 pm, Chris Sutcliffe wrote: > It seems that the $with_cross_host is catching the MinGW based compile > as well. Do I add a rule explicitly for MinGW: > > ifneq (,$(findstring mingw,$(target_alias))) > inst_includedir:=$(includedir) > inst_libdir:=$(libdir) > else Please don't. It's horrific enough already; let's fix it so that this logic is resolved where it belongs -- in the configure script. > Though that seems to defeat the purpose of the file 'else'. I'd > appreciate some help here, given that autotools are really not my > strong suit. Well, this is logic within the Makefile itself, which doesn't really fall into the realm of autotools at all; but maybe this *should* be handled at the autoconf level. If appropriate testing was specified in configure.ac, (or configure.in in this case, since winsup autoconfigury doesn't seem to have evolved since the Dark Ages), then this sort of logic really should not be required in Makefile.in. Regards, Keith. |
From: Chris S. <ir0...@gm...> - 2006-09-10 19:58:12
|
> > Though that seems to defeat the purpose of the file 'else'. I'd > > appreciate some help here, given that autotools are really not my > > strong suit. > > Well, this is logic within the Makefile itself, which doesn't really fall > into the realm of autotools at all; but maybe this *should* be handled at > the autoconf level. If appropriate testing was specified in configure.ac, > (or configure.in in this case, since winsup autoconfigury doesn't seem to > have evolved since the Dark Ages), then this sort of logic really should > not be required in Makefile.in. So do we have any takers for making the required modifications to configure.in? With respect to Makefile.in: ifneq (,$with_cross_host) inst_includedir:=$(tooldir)/include/w32api inst_libdir:=$(tooldir)/lib else is this correct? Why are the w32api headers being separated in to their own directory while the w32api libraries are put in the same directory as all the other libraries? Should it just be $(tooldir)/include for the inst_includedir? Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org |
From: Keith M. <kei...@us...> - 2006-09-10 20:08:12
|
On Sunday 10 September 2006 8:58 pm, Chris Sutcliffe wrote: > If appropriate testing was specified in configure.ac, > > > (or configure.in in this case, since winsup autoconfigury doesn't > > seem to have evolved since the Dark Ages), then this sort of logic > > really should not be required in Makefile.in. > > So do we have any takers for making the required modifications to > configure.in? I'll tak a look at it. > With respect to Makefile.in: > > ifneq (,$with_cross_host) > inst_includedir:=$(tooldir)/include/w32api > inst_libdir:=$(tooldir)/lib > else > > is this correct? Why are the w32api headers being separated in to > their own directory while the w32api libraries are put in the same > directory as all the other libraries? Should it just be > $(tooldir)/include for the inst_includedir? It may not be correct. I'll have a better idea when I look into configure.in, aclocal.m4 and Makefile.in, for the three really need to be considered together. Regards, Keith. |
From: Earnie B. <ea...@us...> - 2006-09-11 12:20:17
|
Quoting Chris Sutcliffe <ir0...@gm...>: > Hey All, > > I just tried to compile w32api for MinGW and found that it's now > throwing all the header files in include/w32api. It's coming from > lib/Makefile.in: > That means that Corrina broke the magic. Only a cygwin target should put the headers in /include/w32api and /include/mingw. Adding cygwin-developers to the distribution. > ifneq (,$(findstring cygwin,$(target_alias))) > inst_includedir:=$(tooldir)/include/w32api > inst_libdir:=$(tooldir)/lib/w32api > else > ifneq (,$with_cross_host) > inst_includedir:=$(tooldir)/include/w32api > inst_libdir:=$(tooldir)/lib > else > inst_includedir:=$(includedir) > inst_libdir:=$(libdir) > endif > endif > > It seems that the $with_cross_host is catching the MinGW based compile > as well. Do I add a rule explicitly for MinGW: > Maybe. > ifneq (,$(findstring mingw,$(target_alias))) > inst_includedir:=$(includedir) > inst_libdir:=$(libdir) > else > > Though that seems to defeat the purpose of the file 'else'. I'd > appreciate some help here, given that autotools are really not my > strong suit. > It used to work. What changed? Earnie Boyd http://shop.siebunlimited.com |
From: Keith M. <kei...@us...> - 2006-09-11 22:30:26
|
On Monday 11 September 2006 1:19 pm, Earnie Boyd wrote: > > I just tried to compile w32api for MinGW and found that it's now > > throwing all the header files in include/w32api. It's coming from > > lib/Makefile.in: > > That means that Corrina broke the magic. Only a cygwin target should > put the headers in /include/w32api and /include/mingw. Adding > cygwin-developers to the distribution. > > > ifneq (,$(findstring cygwin,$(target_alias))) > > inst_includedir:=$(tooldir)/include/w32api > > inst_libdir:=$(tooldir)/lib/w32api > > else > > ifneq (,$with_cross_host) Well, this is wrong in any case; what is `$w'? No matter, the appended `ith_cross_host' can never be null, so this is always true anyway. But even allowing that this is a typo, the whole $(with_cross_host) thing is dubious; in configure.in I see an AC_SUBST for `with_cross_host', but nothing to ever assign a value to it, so it will *always* propagate from configure to `Makefile' as a null string. What is its intended purpose? > > inst_includedir:=$(tooldir)/include/w32api > > inst_libdir:=$(tooldir)/lib > > else > > inst_includedir:=$(includedir) > > inst_libdir:=$(libdir) > > endif > > endif As I noted yesterday, this logic really should be handled at the configure level; putting it thus, in the Makefile, is just plain ugly, and unnecessary. I stand by my offer to clean it up, but it will not be a quick fix. Regards, Keith. |
From: Christopher F. <cgf...@cy...> - 2006-09-11 16:07:29
|
On Mon, Sep 11, 2006 at 08:19:59AM -0400, Earnie Boyd wrote: >Quoting Chris Sutcliffe <ir0...@gm...>: > >> Hey All, >> >> I just tried to compile w32api for MinGW and found that it's now >> throwing all the header files in include/w32api. It's coming from >> lib/Makefile.in: >> > >That means that Corrina broke the magic. Only a cygwin target should >put the headers in /include/w32api and /include/mingw. Adding >cygwin-developers to the distribution. > >> ifneq (,$(findstring cygwin,$(target_alias))) >> inst_includedir:=$(tooldir)/include/w32api >> inst_libdir:=$(tooldir)/lib/w32api >> else >> ifneq (,$with_cross_host) >> inst_includedir:=$(tooldir)/include/w32api >> inst_libdir:=$(tooldir)/lib >> else >> inst_includedir:=$(includedir) >> inst_libdir:=$(libdir) >> endif >> endif >> >> It seems that the $with_cross_host is catching the MinGW based compile >> as well. Do I add a rule explicitly for MinGW: >> > >Maybe. > >> ifneq (,$(findstring mingw,$(target_alias))) >> inst_includedir:=$(includedir) >> inst_libdir:=$(libdir) >> else >> >>Though that seems to defeat the purpose of the file 'else'. I'd >>appreciate some help here, given that autotools are really not my >>strong suit. > >It used to work. What changed? Corinna was trying to get things working so that a cross-mingw environment could be built for Linux. Looking at the configure code, it's obvious that the with_cross_host test is too broad of a test for what she was trying to do. Since she isn't going to be around for a while, I'm going to back out the problematic part of her code. I suspect that just changing the ifneq (,$with_cross_host) to something which specifically tests for mingw is probably the right solution, but I'll work with Corinna on that when she gets back. cgf |
From: Chris S. <ir0...@gm...> - 2006-09-12 22:29:40
|
> Corinna was trying to get things working so that a cross-mingw > environment could be built for Linux. Looking at the configure code, > it's obvious that the with_cross_host test is too broad of a test for > what she was trying to do. > > Since she isn't going to be around for a while, I'm going to back out > the problematic part of her code. I suspect that just changing the > > ifneq (,$with_cross_host) > > to something which specifically tests for mingw is probably the right > solution, but I'll work with Corinna on that when she gets back. As Keith pointed out, there is typo in the line, changing it to: ifneq (,$(with_cross_host)) seems to have fixed the problem (for me anyway). I committed the change to CVS yesterday. Cheers! Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org |
From: Keith M. <kei...@us...> - 2006-09-12 22:56:25
|
On Monday 11 September 2006 5:07 pm, Christopher Faylor wrote: > >>I'd appreciate some help here, given that autotools are really not my > >>strong suit. > > > >It used to work. What changed? > > Corinna was trying to get things working so that a cross-mingw > environment could be built for Linux. Looking at the configure code, > it's obvious that the with_cross_host test is too broad of a test for > what she was trying to do. Perhaps Corinna should talk to us. Both Michael Gerdau and I have been successfully building, and running cross-mingw on Linux for quite some time, and I know we are not alone. > Since she isn't going to be around for a while, I'm going to back out > the problematic part of her code. I suspect that just changing the > > ifneq (,$with_cross_host) Well, that is syntactically invalid. I've already pointed out the typo, and Chris Sutcliffe has corrected it. > to something which specifically tests for mingw is probably the right > solution, but I'll work with Corinna on that when she gets back. I won't claim to be an autoconf expert, but I have been using it extensively for between two and three years now, so I'd like to think I have attained a fair level of competence. I've also been looking at the autoconfigury for both w32api and mingw-runtime. It is a mess, and I've already started to clean it up. I do not understand some of the things Corinna did, and would welcome an opportunity to discuss them with her. Please ask her to contact me on her return. BTW, I've moderated this posting through, on this occasion; please use your subscribed address for future postings, or advise if you would like me to enter a subscription for this one. Regards, Keith. |
From: Christopher F. <cgf...@cy...> - 2006-09-13 00:00:46
|
On Wed, Sep 13, 2006 at 12:01:19AM +0100, Keith Marshall wrote: >On Monday 11 September 2006 5:07 pm, Christopher Faylor wrote: >> >>I'd appreciate some help here, given that autotools are really not my >> >>strong suit. >> > >> >It used to work. ?What changed? >> >> Corinna was trying to get things working so that a cross-mingw >> environment could be built for Linux. ?Looking at the configure code, >> it's obvious that the with_cross_host test is too broad of a test for >> what she was trying to do. > >Perhaps Corinna should talk to us. Both Michael Gerdau and I have been >successfully building, and running cross-mingw on Linux for quite some >time, and I know we are not alone. She discussed what she was trying to do when she submitted the patch to mingw-patches. >> Since she isn't going to be around for a while, I'm going to back out >> the problematic part of her code. ?I suspect that just changing the >> >> ifneq (,$with_cross_host) > >Well, that is syntactically invalid. I've already pointed out the typo, >and Chris Sutcliffe has corrected it. The email that you are responding to was sent at 2006-09-11 16:07 GMT. My CVS checking was a couple of minutes earlier. Your email noticing of the typo was on something like 2006-09-11 22:33 GMT. Chris Suttcliffe's email was from today. Perhaps the confusion comes from the fact that although you only approved my email to mingw-dvlpr today, it was actually sent yesterday. However, I just erroneously backed out Corinna's change from the mingw Makefile rather than the w32api/lib Makefile and friends. That was my mistake. Regardless, I didn't think that the Makefile.in change was right anyway and since it was apparently only to benefit Corinna's particular usage, I thought backing it out and working with her when she returns made some sense. I just backed out the change in the wrong file and I apologize for putting Chris to extra work for that. >>to something which specifically tests for mingw is probably the right >>solution, but I'll work with Corinna on that when she gets back. > >I won't claim to be an autoconf expert, but I have been using it >extensively for between two and three years now, so I'd like to think I >have attained a fair level of competence. If nothing else, you certainly seem to have achieved the je ne sais quoi attitude that goes with working on free software. >I've also been looking at the autoconfigury for both w32api and >mingw-runtime. It is a mess, Yes, I got this point. You have mentioned it repeatedly. I can't speak for anyone else, but I don't think you need to mention it again. >and I've already started to clean it up. I do not understand some of >the things Corinna did, and would welcome an opportunity to discuss >them with her. Please ask her to contact me on her return. Mentioning that I would work with her was merely meant to convey that I wasn't expecting anyone else's help. It wasn't an indication that she worked for me or vice versa. If you want to talk to her, then go right ahead and send her email. >BTW, I've moderated this posting through, on this occasion; please use >your subscribed address for future postings, or advise if you would like >me to enter a subscription for this one. The cygwin.com pseudo-address is what I use when sending email to cygwin lists. It will only show up when messages are cross-posted. If you have some way to allow that email address in the From: without actually trying to send email to it, then, sure, go ahead and set that up. cgf |
From: Keith M. <kei...@us...> - 2006-09-14 17:29:08
|
On Wednesday 13 September 2006 1:00 am, Christopher Faylor wrote: > >Perhaps Corinna should talk to us. Both Michael Gerdau and I have > > been successfully building, and running cross-mingw on Linux for > > quite some time, and I know we are not alone. > > She discussed what she was trying to do when she submitted the patch to > mingw-patches. It would have been better discussed here; mingw-patches is virtually disused -- indeed we have discussed shutting it down altogether, and we probably should go ahead and do so. > >> Since she isn't going to be around for a while, I'm going to back > >> out the problematic part of her code. ?I suspect that just changing > >> the > >> > >> ifneq (,$with_cross_host) > > > >Well, that is syntactically invalid. I've already pointed out the > > typo, and Chris Sutcliffe has corrected it. > > The email that you are responding to was sent at 2006-09-11 16:07 GMT. > My CVS checking was a couple of minutes earlier. Your email noticing > of the typo was on something like 2006-09-11 22:33 GMT. Chris > Suttcliffe's email was from today. > > Perhaps the confusion comes from the fact that although you only > approved my email to mingw-dvlpr today, it was actually sent yesterday. This is almost certainly the case. I intended no criticism; I was merely pointing out that the original typo has now been corrected. > >I've also been looking at the autoconfigury for both w32api and > >mingw-runtime. It is a mess, > > Yes, I got this point. You have mentioned it repeatedly. I can't > speak for anyone else, but I don't think you need to mention it again. Well, if I seemed to be repeating myself excessively, it was because I was getting no feedback to confirm that you had taken my concerns on board... > >and I've already started to clean it up. I do not understand some of > >the things Corinna did, and would welcome an opportunity to discuss > >them with her. Please ask her to contact me on her return. > > Mentioning that I would work with her was merely meant to convey that I > wasn't expecting anyone else's help. ...and, since I'd already offered that help, and indeed had already started looking into possible resolutions, I simply wanted to avoid us working on it independently, and pulling in different directions. > If you want to talk to her, then go right ahead and send her email. I'll do that. I'll not commit anything new, until we've established a dialogue, and had an opportunity to agree the way forward. > The cygwin.com pseudo-address is what I use when sending email to > cygwin lists. It will only show up when messages are cross-posted. > > If you have some way to allow that email address in the From: without > actually trying to send email to it, then, sure, go ahead and set that > up. I've added your pseudo-address to the list of approved non-subscribing posters. Regards, Keith. |