From: Chris S. <ir0...@gm...> - 2005-08-18 18:24:42
|
Hey All, I'm going to assume that the proposed changes to the w32api and runtime Makefile.in to strip the binaries (with the '-g' options) is acceptable. As such, I'm going to hopefully put together new builds of w32api and runtime tomorrow. Since there are additional changes to w32api, I'm fine with incrementing the release number. However, the only change in runtime is the Makefile.in change. Is there any objection to incrementing the release number? Cheers! Chris --=20 Chris Sutcliffe ir0...@gm... http://emergedesktop.org http://ironhead.modblog.com |
From: Julien L. <lec...@fr...> - 2005-08-18 18:55:15
|
Hi, I've also recently compiled cygwin with cygwin with the w32api I've been working on. In a few words: I ported the w32api to automake/autoconf If it x-compiles without a problem, then it would be good to do the = switch. More info available here: https://sourceforge.net/tracker/?func=3Ddetail&atid=3D302435&aid=3D121310= 3&group_i d=3D2435 Julien > -----Original Message----- > From: min...@li...=20 > [mailto:min...@li...] On Behalf Of=20 > Chris Sutcliffe > Sent: mercredi 17 ao=FBt 2005 23:50 > To: MinGW-dvlpr > Subject: [MinGW-dvlpr] New runtime and w32api releases >=20 > Hey All, >=20 > I'm going to assume that the proposed changes to the w32api=20 > and runtime Makefile.in to strip the binaries (with the '-g'=20 > options) is acceptable. As such, I'm going to hopefully put=20 > together new builds of w32api and runtime tomorrow. >=20 > Since there are additional changes to w32api, I'm fine with=20 > incrementing the release number. However, the only change in=20 > runtime is the Makefile.in change. Is there any objection to=20 > incrementing the release number? >=20 > Cheers! >=20 > Chris >=20 > -- > Chris Sutcliffe > ir0...@gm... > http://emergedesktop.org > http://ironhead.modblog.com >=20 >=20 > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development=20 > Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams *=20 > Testing & QA > Security * Process Improvement & Measurement *=20 > http://www.sqe.com/bsce5sf > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr >=20 |
From: Chris S. <ir0...@gm...> - 2005-08-18 19:49:21
|
Hey, > I've also recently compiled cygwin with cygwin with the w32api I've been > working on. > In a few words: I ported the w32api to automake/autoconf So you've tested it with Cygwin and MSys? > If it x-compiles without a problem, then it would be good to do the switc= h. >=20 > More info available here: > https://sourceforge.net/tracker/?func=3Ddetail&atid=3D302435&aid=3D121310= 3&group_i > d=3D2435 I've grabbed the diff, I'll give it a shot tomorrow. Thanx! Chris --=20 Chris Sutcliffe ir0...@gm... http://emergedesktop.org http://ironhead.modblog.com |
From: Earnie B. <ea...@us...> - 2005-08-20 14:57:37
|
On 7:48:30 pm 2005-08-18 Chris Sutcliffe <ir0...@gm...> wrote: > Hey, > > > I've also recently compiled cygwin with cygwin with the w32api > > I've been working on. > > In a few words: I ported the w32api to automake/autoconf > > So you've tested it with Cygwin and MSys? > > > If it x-compiles without a problem, then it would be good to do > > the switch. > > More info available here: > > https://sourceforge.net/tracker/?func=detail&atid=302435&aid=121310 > 3&group_i > > d=2435 > > I've grabbed the diff, I'll give it a shot tomorrow. > Don't get too hasty, Julien's patch must be approved before being applied. I've just sent a request to CGF to take a look and when I get a round tuit, I'll take a look as well. Earnie |
From: Christopher F. <me...@cg...> - 2005-08-20 17:43:55
|
On Sat, Aug 20, 2005 at 02:57:55PM +0000, Earnie Boyd wrote: >On 7:48:30 pm 2005-08-18 Chris Sutcliffe <ir0...@gm...> wrote: >> Hey, >> >> > I've also recently compiled cygwin with cygwin with the w32api >> > I've been working on. >> > In a few words: I ported the w32api to automake/autoconf >> >> So you've tested it with Cygwin and MSys? >> >> > If it x-compiles without a problem, then it would be good to do >> > the switch. >> > More info available here: >> > https://sourceforge.net/tracker/?func=detail&atid=302435&aid=121310 >> 3&group_i >> > d=2435 >> >> I've grabbed the diff, I'll give it a shot tomorrow. >> > >Don't get too hasty, Julien's patch must be approved before being applied. >I've just sent a request to CGF to take a look and when I get a round tuit, >I'll take a look as well. What is the rationale for moving to automake? cgf |
From: Julien L. <lec...@fr...> - 2005-08-21 18:41:27
|
> >> > <snip> > >> > > https://sourceforge.net/tracker/?func=detail&atid=302435&aid=121310 > >> 3&group_i > >> > d=2435 > >> > <snip> > > What is the rationale for moving to automake? > > cgf > I guess I never said why I was porting w32api to automake (and once that is done, I'll probably work on ming-runtime and so on). Here's why I took this task : 1 - Currently, there's some "make clean" issues where not everything is cleaned (ie: in dx dir). This happens when making is src directory (btw, not usually recommended for any package) 2 - Better flag handling. 3 - Better handling of $AS (assembler for dlltool) and assembler flags 4 - Being able to easily add flags to dlltool. 5 - Compiling GL, Dx & DDk on demand or by target. 6 - A testsuite generated by autotest. Easy to maintain and expand. So instead of working on just Makefiles.in, I preferred porting it to automake. J |
From: Keith M. <kei...@nt...> - 2005-08-21 19:38:32
|
On Sunday 21 August 2005 7:41 pm, you wrote: > > >> > <snip> > > > > https://sourceforge.net/tracker/?func=detail&atid=302435&aid=121310 > > > > >> 3&group_i > > >> > > >> > d=2435 > > > > <snip> > > > > What is the rationale for moving to automake? > > > > cgf > > I guess I never said why I was porting w32api to automake (and once that is > done, I'll probably work on ming-runtime and so on). Oh. Please DON'T!!! > Here's why I took this task : > 1 - Currently, there's some "make clean" issues where not everything is > cleaned (ie: in dx dir). This happens when making is src directory (btw, > not usually recommended for any package) > 2 - Better flag handling. > 3 - Better handling of $AS (assembler for dlltool) and assembler flags > 4 - Being able to easily add flags to dlltool. > 5 - Compiling GL, Dx & DDk on demand or by target. > 6 - A testsuite generated by autotest. Easy to maintain and expand. > > So instead of working on just Makefiles.in, I preferred porting it to > automake. So now you have a grossly bloated, and utterly incomprehensible Makefile :-( Ah well, I suppose it fits well with the Microsoft development paradigm of making life difficult for the user. Just my 2c. I like autoconf, but I absolutely detest automake. I can make sense of a clean Makefile.in, and it's easy to add new functionality, in a controlled fashion. Bring automake into the equation, and for free you get: - hideous syntax in Makefile.am - 10-fold increase in bloat - loads of unnecessary dependencies - complete incomprehensibility. I'm afraid I can see no advantage, for any project, in using automake. Autoconf, OTOH, offers significant benefit to the cross platform developer. Cheers, Keith. |
From: Christopher F. <me...@cg...> - 2005-08-22 03:43:51
|
On Sun, Aug 21, 2005 at 08:41:26PM +0100, Keith Marshall wrote: >On Sunday 21 August 2005 7:41 pm, you wrote: >> > >> > <snip> >> > >> > https://sourceforge.net/tracker/?func=detail&atid=302435&aid=121310 >> > >> > >> 3&group_i >> > >> >> > >> > d=2435 >> > >> > <snip> >> > >> > What is the rationale for moving to automake? >> > >> > cgf >> >> I guess I never said why I was porting w32api to automake (and once that is >> done, I'll probably work on ming-runtime and so on). > >Oh. Please DON'T!!! > >> Here's why I took this task : >> 1 - Currently, there's some "make clean" issues where not everything is >> cleaned (ie: in dx dir). This happens when making is src directory (btw, >> not usually recommended for any package) >> 2 - Better flag handling. >> 3 - Better handling of $AS (assembler for dlltool) and assembler flags >> 4 - Being able to easily add flags to dlltool. >> 5 - Compiling GL, Dx & DDk on demand or by target. >> 6 - A testsuite generated by autotest. Easy to maintain and expand. >> >> So instead of working on just Makefiles.in, I preferred porting it to >> automake. > >So now you have a grossly bloated, and utterly incomprehensible Makefile :-( >Ah well, I suppose it fits well with the Microsoft development paradigm of >making life difficult for the user. > >Just my 2c. I like autoconf, but I absolutely detest automake. I can make >sense of a clean Makefile.in, and it's easy to add new functionality, in a >controlled fashion. Bring automake into the equation, and for free you get: > >- hideous syntax in Makefile.am >- 10-fold increase in bloat >- loads of unnecessary dependencies >- complete incomprehensibility. > >I'm afraid I can see no advantage, for any project, in using automake. >Autoconf, OTOH, offers significant benefit to the cross platform developer. I agree with almost all of the above. I really don't like automake. I think that autoconf is also a necessary evil. I'm not really enamored of any of the auto tools. cgf |
From: Aaron W. L. <aar...@aa...> - 2005-08-21 20:26:04
|
Keith Marshall wrote: > Just my 2c. I like autoconf, but I absolutely detest automake. I can make > sense of a clean Makefile.in, and it's easy to add new functionality, in a > controlled fashion. Bring automake into the equation, and for free you get: > > - hideous syntax in Makefile.am > - 10-fold increase in bloat > - loads of unnecessary dependencies > - complete incomprehensibility. > > I'm afraid I can see no advantage, for any project, in using automake. > Autoconf, OTOH, offers significant benefit to the cross platform developer. Since you've written so strongly against automake, I should write briefly to point out many people really like automake. Interestingly, the reasons I like automake are because I find it has the opposite of the characteristics you mention. I am confused that you say its ugly and complex, because it allows me to write Makefiles that are extremely short and simple, usually only a few lines long, even for many objects and other files. The amount of boilerplate code I need to write is kept to a minimum. I generally support automake-izing where possible, but I can see three legitimate disadvantages: -It requires having all developers use the same automake version, and agree to upgrading in an organized fashion. -w32api needs support for cross compilation configurations, which automake does support, but may be more complicated. automake's support for this has been criticized in the past--I am not sure where it stands now. -It might make builds slightly slower, and can make regenerating Makefile.in/configure.in (only done by maintainers) hugely slow. If the project is libtoolized as well, this is doubly true for both cases. Aaron W. LaFramboise |
From: Earnie B. <ea...@us...> - 2005-08-21 21:15:19
|
On 8:26:02 pm 2005-08-21 "Aaron W. LaFramboise" <aar...@aa...> wrote: > Keith Marshall wrote: > > > Just my 2c. I like autoconf, but I absolutely detest automake. I > > can make sense of a clean Makefile.in, and it's easy to add new > > functionality, in a controlled fashion. Bring automake into the > > equation, and for free you get: > > - hideous syntax in Makefile.am > > - 10-fold increase in bloat > > - loads of unnecessary dependencies > > - complete incomprehensibility. > > > > I'm afraid I can see no advantage, for any project, in using > > automake. Autoconf, OTOH, offers significant benefit to the cross > platform developer. > > Since you've written so strongly against automake, I should write > briefly to point out many people really like automake. I'm not as strongly opposed as Keith is but I'm hesitant at best. > Interestingly, the reasons I like automake are because I find it has > the opposite of the characteristics you mention. > > I am confused that you say its ugly and complex, because it allows me > to write Makefiles that are extremely short and simple, usually only > a few lines long, even for many objects and other files. The amount > of boilerplate code I need to write is kept to a minimum. > > I generally support automake-izing where possible, but I can see > three legitimate disadvantages: > > -It requires having all developers use the same automake version, and > agree to upgrading in an organized fashion. > This should be too big a challenge. But it may be disconcerting when adding new items to the w32api. > -w32api needs support for cross compilation configurations, which > automake does support, but may be more complicated. automake's > support for this has been criticized in the past--I am not sure where > it stands now. > You will need to test cross compilation with your changes. We cannot afford to break this. > -It might make builds slightly slower, and can make regenerating > Makefile.in/configure.in (only done by maintainers) hugely slow. If > the project is libtoolized as well, this is doubly true for both > cases. > Slowing down the build just to automakeize the package isn't worth it. Libtool is definitely objected to. I will not approve the use of libtool in the w32api and mingw-runtime builds. Earnie |
From: Julien L. <lec...@fr...> - 2005-08-21 22:04:08
|
> Keith Marshall wrote: > > > Just my 2c. I like autoconf, but I absolutely detest > automake. I can > > make sense of a clean Makefile.in, and it's easy to add new > > functionality, in a controlled fashion. Bring automake > into the equation, and for free you get: > > > > - hideous syntax in Makefile.am - Same could be said and but also unsaid about C : everything depends on your coding style. > > - 10-fold increase in bloat - True, but it's compressed by 90 % in a tar-gz so no real size impact on downloading. - Otherwise, by now, it's no longer a valid argument (on any widestream computer) for a developper. End-users should on the other hand, have stripped down binaries and resources that go with it (and end-users don't get the Makefiles !). > > - loads of unnecessary dependencies - Uh ? Which ones ? Apart from automake to build the makefiles.in, I see none. > > - complete incomprehensibility. - Of Makefile.am ? See first answer above. - Of Makefile.in ? You shouldn't play with them anymore since the purpose of automake is build them. > Aaron W. LaFramboise wrote : > <snip> > > I generally support automake-izing where possible, but I can > see three legitimate disadvantages: > > -It requires having all developers use the same automake > version, and agree to upgrading in an organized fashion. I've never encountered such a problem. I don't think that automake dev's are breaking downward compatibility when releasing a new version. > -w32api needs support for cross compilation configurations, > which automake does support, but may be more complicated. > automake's support for this has been criticized in the > past--I am not sure where it stands now. It looks pretty much stable for at least some time. > -It might make builds slightly slower, and can make > regenerating Makefile.in/configure.in (only done by > maintainers) hugely slow. If the project is libtoolized as > well, this is doubly true for both cases. Libtool for automake is a pain in the a**, and that's why I didn't use it in w32api. I think that libtool badly handles dll and dll import lib building (at least, I've never seen a good example of how it makes it easier). I totally agree with Earnie to keep libtool out of the make process. Otherwise, for maintainers, the build time for automake regeneration of makefiles is pretty quick. For non-maintainers, there's no increase in build time, and if you notice an increase in build time, I'm sure it's just because you're psychologically not inclined to give automake a chance to prove it's worth it. My only real concern about porting w32api to automake is how Cygwin build process would react to this change. As for now, it worked for me. Cygwin uses Makefiles.in and no automake. Because they felt like it (=> hideous syntax in Makefile.in) they pass CFLAGS in the CC environment and other similar ugly stuff. I can understand that we can hesitate on such a switch : the fear of breaking stuff. That's why I still want this change to have extensive testing (and I doubt someone would dare disagree to this). On the other hand, automake has all the functionality of plain makefiles, and you just add ease of use on top. Why refuse that ? Julien |
From: Aaron W. L. <aar...@aa...> - 2005-08-21 23:21:42
|
Julien Lecomte wrote: > > >>Keith Marshall wrote: >> >> >>>Just my 2c. I like autoconf, but I absolutely detest >> >>automake. I can >> >>>make sense of a clean Makefile.in, and it's easy to add new >>>functionality, in a controlled fashion. Bring automake >> >>into the equation, and for free you get: >> >>>- hideous syntax in Makefile.am > > > - Same could be said and but also unsaid about C : everything depends on > your coding style. > > >>>- 10-fold increase in bloat > > > - True, but it's compressed by 90 % in a tar-gz so no real size impact on > downloading. > - Otherwise, by now, it's no longer a valid argument (on any widestream > computer) for a developper. End-users should on the other hand, have > stripped down binaries and resources that go with it (and end-users don't > get the Makefiles !). > > >>>- loads of unnecessary dependencies > > > - Uh ? Which ones ? Apart from automake to build the makefiles.in, I see > none. > > >>>- complete incomprehensibility. > > > - Of Makefile.am ? See first answer above. > - Of Makefile.in ? You shouldn't play with them anymore since the purpose of > automake is build them. > > >>Aaron W. LaFramboise wrote : >><snip> >> >>I generally support automake-izing where possible, but I can >>see three legitimate disadvantages: >> >>-It requires having all developers use the same automake >>version, and agree to upgrading in an organized fashion. > > I've never encountered such a problem. I don't think that automake dev's are > breaking downward compatibility when releasing a new version. This comment is based on observation of automake usage in other projects, most significantly GCC. As Earnie Boyd points out, its not a huge problem, but its nice to have everyone using the same version, and to exercise care when upgrading to newer versions, because this can very easily break already-fragile things like cross-compiling. Simple instructions in Makefile.am or README regarding what version of automake to use, and how to upgrade to a new version, would be sufficient. > My only real concern about porting w32api to automake is how Cygwin build > process would react to this change. As for now, it worked for me. Cygwin > uses Makefiles.in and no automake. Because they felt like it (=> hideous > syntax in Makefile.in) they pass CFLAGS in the CC environment and other > similar ugly stuff. I noticed when I began working on a (yet unreleased) mingwrt testcase that the present Makefile.in uses the wrong variable names, at least with regard to the ordinary GNU/Cygnus conventions. For example, as I recall, the variable ordinarily used for the build CC was used for the target CC. I'm not sure if those problems would actually manifest themselves in incorrect compilation, or they're just mistakes or oversights in convention. In any case, the use as-is will almost certainly cause problems for automake. If the agreement is that you should convert to automake, you'll want to fix this for the automake-ized version. However, you should be wary of cases where the parent Makefile in a unified or Cygwin tree has different conventions regarding this variable. Also, users may be used to passing certain variables directly to make (such as CFLAGS in a crossbuild) which will have a different meaning after automake-ization, and so you'll want to make sure this works or fails as gracefully as possible. Aaron W. LaFramboise |
From: Chris S. <ir0...@gm...> - 2005-08-20 15:40:42
|
> > I've grabbed the diff, I'll give it a shot tomorrow. >=20 > Don't get too hasty, Julien's patch must be approved before being applied= . > I've just sent a request to CGF to take a look and when I get a round tui= t, > I'll take a look as well. K. I'll just proceed with modifying the Makefile.in for now and create new runtime and w32api releases that are stripped. Cheers! Chris --=20 Chris Sutcliffe ir0...@gm... http://emergedesktop.org http://ironhead.modblog.com |
From: Earnie B. <ea...@us...> - 2005-08-20 15:48:46
|
On 3:40:33 pm 2005-08-20 Chris Sutcliffe <ir0...@gm...> wrote: > > > I've grabbed the diff, I'll give it a shot tomorrow. > > > > Don't get too hasty, Julien's patch must be approved before being > > applied. I've just sent a request to CGF to take a look and when I > > get a round tuit, I'll take a look as well. > > K. I'll just proceed with modifying the Makefile.in for now and > create new runtime and w32api releases that are stripped. > make clean && make dist CFLAGS='-s -O3 -mms-bitfields -mtune=i686' Earnie P.S.: Sorry, I forgot about that bit of information. |