From: M. L. <meh...@co...> - 2003-09-23 08:48:17
|
Hi It seems to me Mesa-5.0.2 has some serious bugs, some of them has already been mentioned in previous email to this list, This bugs may not be part of the actual program, but it the way Mesa is built using configure script. I think you should either pull it out or release another version soon. Thanks __Mehdi |
From: Brian P. <br...@tu...> - 2003-09-23 13:46:13
|
M. Lavasani wrote: > Hi > > It seems to me Mesa-5.0.2 has some serious bugs, some of them has already been > mentioned in previous email to this list, This bugs may not be part of the > actual program, but it the way Mesa is built using configure script. > I think you should either pull it out or release another version soon. Well, there have been a few reports of trouble with autoconf/libtool in 5.0.2, but not many. Evidently, it's working for most people. I'd fix the problem, if I knew what it was. In any case, autoconf/automake/libtool has been stripped out of Mesa already and won't be in the next release (5.1). -Brian |
From: M. L. <meh...@co...> - 2003-09-23 14:32:57
|
> > > > It seems to me Mesa-5.0.2 has some serious bugs, some of them has already been > > mentioned in previous email to this list, This bugs may not be part of the > > actual program, but it the way Mesa is built using configure script. > > I think you should either pull it out or release another version soon. > > Well, there have been a few reports of trouble with autoconf/libtool > in 5.0.2, but not many. Evidently, it's working for most people. I'd > fix the problem, if I knew what it was. I don't think it is possible to compile Mesa using Makefile generated by configure. yes, you may compile it using the old style Makefile, or hack the Makefile generated from the configure file. Apart from the two above option there is no way to COMPLETELY compile Mesa. you may do it partially, > > In any case, autoconf/automake/libtool has been stripped out of Mesa > already and won't be in the next release (5.1). > This is absolutely a sad news. It seems instead of Mesa moving forward, it is going backward!! I 've been porting Mesa to HPUX for years now: http://hpux.connect.org.uk/hppd/hpux/Development/Libraries/Mesa-5.0/ I started porting to HPUX version 10.20-11.00 and then 11.00-11.20 and finally now I am porting it to 11.00-11.22 platforms. Since there are lot of differences between 11.00 and 11.22 platforms in the way the libraries are build and installed, going back to the idea of building Mesa using conventional Makefile is horrifiying. Thanks __Mehdi |
From: Brian P. <br...@tu...> - 2003-09-23 15:05:42
|
M. Lavasani wrote: >>>It seems to me Mesa-5.0.2 has some serious bugs, some of them has already been >>>mentioned in previous email to this list, This bugs may not be part of the >>>actual program, but it the way Mesa is built using configure script. >>>I think you should either pull it out or release another version soon. >> >>Well, there have been a few reports of trouble with autoconf/libtool >>in 5.0.2, but not many. Evidently, it's working for most people. I'd >>fix the problem, if I knew what it was. > > > I don't think it is possible to compile Mesa using Makefile generated by configure. > yes, you may compile it using the old style Makefile, or hack the Makefile > generated from the configure file. Apart from the two above > option there is no way to COMPLETELY compile Mesa. you may do it partially, > > > >>In any case, autoconf/automake/libtool has been stripped out of Mesa >>already and won't be in the next release (5.1). >> > > > This is absolutely a sad news. It seems instead of Mesa moving forward, it is > going backward!! > > I 've been porting Mesa to HPUX for years now: > > http://hpux.connect.org.uk/hppd/hpux/Development/Libraries/Mesa-5.0/ Could you update the info there? I haven't used that email address in over 4 years (but don't put my current email address there - I don't want my address to get harvested by more spammers). Also, the license (on core Mesa anyway) is XFree86-style, not GPL. > I started porting to HPUX version 10.20-11.00 and then 11.00-11.20 and finally > now I am porting it to 11.00-11.22 platforms. Since there are lot of differences between > 11.00 and 11.22 platforms in the way the libraries are build and installed, > going back to the idea of building Mesa using conventional Makefile is > horrifiying. Over the years, the autoconf/automake/libtool stuff has been a PITA to maintain. It seems to seldom work on non-Linux platforms and is just overly complicated. The libtool script, for example is 151KB in size (5K lines for crying out loud!) and almost impossible to debug. When I did the big directory re-org a few months ago I stripped it all out. Boy was that a pleasure! If someone wants to step up to contribute new autoconf/automake support I'll reconsider adding it back in, as long as it meets my requirements. I've also been tinkering with SCONS (http://www.scons.org/) but I'm not ready to commit to it yet. As for HPUX, I encourage you to download the Mesa CVS trunk and test that. The new bin/mklib script is used for making shared libs now. It's a heck of a lot simpler than libtool. -Brian |
From: Marcelo E. M. <mma...@de...> - 2003-09-25 14:56:42
|
On Tue, Sep 23, 2003 at 09:06:23AM -0600, Brian Paul wrote: > If someone wants to step up to contribute new autoconf/automake > support I'll reconsider adding it back in, as long as it meets my > requirements. Which are? (I'm sorry if you stated them elsewhere on the thread, but I didn't spot them) -- Marcelo |
From: Keith W. <ke...@tu...> - 2003-09-25 16:47:27
|
Marcelo E. Magallon wrote: > On Tue, Sep 23, 2003 at 09:06:23AM -0600, Brian Paul wrote: > > > If someone wants to step up to contribute new autoconf/automake > > support I'll reconsider adding it back in, as long as it meets my > > requirements. > > Which are? (I'm sorry if you stated them elsewhere on the thread, but > I didn't spot them) My biggest one (whatever Brian's are) is that it must not ever even think about using libtool. Autoconf compiles spent as much time inside libtool.sh as they did inside gcc. Why to you need thousands of lines of shell script just to run 'cc'? Frankly I'm personally pretty uninterested in seeing autoconf/automake come back in. I'd be happy to see some clean GNU makefiles or similar replace the current somewhat bodged system and maybe do a better job of handling dependencies - but that's about the extent of it. Does the current build system not compile for you? Keith |
From: M. L. <meh...@co...> - 2003-09-26 08:51:58
|
> > Marcelo E. Magallon wrote: > > On Tue, Sep 23, 2003 at 09:06:23AM -0600, Brian Paul wrote: > > > > > If someone wants to step up to contribute new autoconf/automake > > > support I'll reconsider adding it back in, as long as it meets my > > > requirements. > > > > Which are? (I'm sorry if you stated them elsewhere on the thread, but > > I didn't spot them) > > My biggest one (whatever Brian's are) is that it must not ever even think > about using libtool. Autoconf compiles spent as much time inside libtool.sh > as they did inside gcc. Why to you need thousands of lines of shell script > just to run 'cc'? > > Frankly I'm personally pretty uninterested in seeing autoconf/automake come > back in. I'd be happy to see some clean GNU makefiles or similar replace the > current somewhat bodged system and maybe do a better job of handling > dependencies - but that's about the extent of it. > I am sorry keith, But I don't agree with you. The whole idea of autoconf, and libtool is to make porting easier, and it has really done the job. My job is porting software and I personally think libtool has changed the face of software porting in a very good way. Take Mesa on HPUX as an example. Mesa still has support in Makefile.X11 for HPUX9x that died many years ago. Even hpux10x is dead. Afther HPUX10x we have following HPUX version: HPUX-11.00 32 bits HPUX-11.00 64 bits HPUX-11.11 32 bits HPUX-11.11 64 bits HPUX-11.22 32 bits (AKA IA64) HPUX-11.22 64 bits (AKA IA64) The way some the above platforms are building and installing library is diferent from others. Now imagine if you want to add the support for all the above platforms and also the other platforms that has been missed by Mesa The result is going to be as complicated as libtool. Then why not useing the libtool?? Ofcourse I understand Brian 's point of view. And I respect that. But I don't agree with the idea of libtool, autoconf and automake are complicated. Yes maybe for the developers, but not for the endusers. Thanks __Mehdi |
From: Keith W. <ke...@tu...> - 2003-09-26 09:35:59
|
M. Lavasani wrote: >>Marcelo E. Magallon wrote: >> >>>On Tue, Sep 23, 2003 at 09:06:23AM -0600, Brian Paul wrote: >>> >>> > If someone wants to step up to contribute new autoconf/automake >>> > support I'll reconsider adding it back in, as long as it meets my >>> > requirements. >>> >>> Which are? (I'm sorry if you stated them elsewhere on the thread, but >>> I didn't spot them) >> >>My biggest one (whatever Brian's are) is that it must not ever even think >>about using libtool. Autoconf compiles spent as much time inside libtool.sh >>as they did inside gcc. Why to you need thousands of lines of shell script >>just to run 'cc'? >> >>Frankly I'm personally pretty uninterested in seeing autoconf/automake come >>back in. I'd be happy to see some clean GNU makefiles or similar replace the >>current somewhat bodged system and maybe do a better job of handling >>dependencies - but that's about the extent of it. >> > > I am sorry keith, But I don't agree with you. The whole idea of autoconf, and > libtool is to make porting easier, and it has really done the job. My job is > porting software and I personally think libtool has changed the face of software > porting in a very good way. Take Mesa on HPUX as an example. Mesa still has > support in Makefile.X11 for HPUX9x that died many years ago. Even hpux10x is dead. > Afther HPUX10x we have following HPUX version: > > HPUX-11.00 32 bits > HPUX-11.00 64 bits > HPUX-11.11 32 bits > HPUX-11.11 64 bits > HPUX-11.22 32 bits (AKA IA64) > HPUX-11.22 64 bits (AKA IA64) > > The way some the above platforms are building and installing library is diferent > from others. > > Now imagine if you want to add the support for all the above platforms and also > the other platforms that has been missed by Mesa > The result is going to be as > complicated as libtool. I believe this is the flaw in your reasoning. > Then why not useing the libtool?? Because it wastes my time by slowing every compilation unnecessarily. > Ofcourse I understand Brian 's point of view. And I respect that. But I don't > agree with the idea of libtool, autoconf and automake are complicated. Yes > maybe for the developers, but not for the endusers. The overwhelming majority of end users don't port mesa or any other software. Anyway, I'll refine my criteria for an autoconf-like cross-platform configuration system: - After an initial discovery/investigation phase, any such system should emit a set of Makefiles that could plausibly have been written by a human, and directly invoke the native tools on the system. I don't have anything against autoconf, etc. I just want it to produce a non-broken build system as an end result. Keith |
From: Brian P. <br...@tu...> - 2003-09-25 17:55:52
|
Marcelo E. Magallon wrote: > On Tue, Sep 23, 2003 at 09:06:23AM -0600, Brian Paul wrote: > > > If someone wants to step up to contribute new autoconf/automake > > support I'll reconsider adding it back in, as long as it meets my > > requirements. > > Which are? (I'm sorry if you stated them elsewhere on the thread, but > I didn't spot them) 1. No libtool: - with libtool, libs and intermediate .a files get put in hidden .lib/ directories which people have trouble finding. - it restricts the version number you can put on libraries. - it wraps all the demo programs with a stupid shell script. - it's a 5K line script that's impossible to debug when something's not working. Keith mentioned other issues 2. Make sure ./configure ; make actually works on IRIX, HPUX, Solaris, etc. and not just on Linux. 3. Find someone who can maintain the autoconf stuff and fix bugs in it. I'm not going to waste my time doing that. I have much better things to spend my time on. -Brian |