Tackilng multiple versions of autoconf
Hi, A peculiar thing I noticed with many ports is they need different versions of autoconf installed (set through the AUTOCONF_VERSION variable) - so in the end, my system has 3 versions after a couple of port builds (2.13, 2.59, and 2.61). The 2.61 version seems to be the latest one. In order to avoid having multiple autoconf versions, I bumped the versions of a couple of ports (cdparanoia, tcl, tk) to the latest (2.61), and built them. They did fine. Is any effort underway, which aims at baselining the autoconf versions across the board? (it need not be the latest, but something which can compile *all* ports). If not, I'd like to volunteer for this effort. Here is how I plan to tackle it: 1. search for AUTOCONF_VERSION= across all port Makefiles, and make a list of all ports that use autoconf 2. try building each port with the latest version of autoconf, and go back one version until the port builds. 3. if all versions are required (wasted effort of 1. and 2.), individually check each port to see what do they need more/less to configure with latest autoconf (if needed contact the port maintainer). 4. iterate through steps 2 and 3, until only one autoconf version is used throughout. It is possible that by the time the above steps are executed, a newer autoconf is released. Maybe in the future, individual port maintainer can be given the responsibility of bumping the autoconf version to the latest. If someone is already working on similar thing, I'd be happy to join him/her. Thanks! -Amarendra
Re: Tackilng multiple versions of autoconf
On 2007/10/16 16:10, Amarendra Godbole wrote: > A peculiar thing I noticed with many ports is they need different versions of > autoconf installed (set through the AUTOCONF_VERSION variable) - so in the > end, my system has 3 versions after a couple of port builds (2.13, 2.59, and > 2.61). This isn't a problem.
Re: Tackilng multiple versions of autoconf
On Tue, Oct 16, 2007 at 11:52:27AM +0100, Stuart Henderson wrote: > On 2007/10/16 16:10, Amarendra Godbole wrote: > > A peculiar thing I noticed with many ports is they need different versions > > of > > autoconf installed (set through the AUTOCONF_VERSION variable) - so in the > > end, my system has 3 versions after a couple of port builds (2.13, 2.59, and > > 2.61). > > This isn't a problem. The OP seems to think it is or he (she?) wouldn't waste his time emailing the list or making an offer to a considerable amount of work to fix it. Rather than just dissing him, why not enlighten us as to why its not a problem? Perhaps address the statement "... they _NEED_ different versions of autoconf installed...". Doug.
Re: Tackilng multiple versions of autoconf
On 10/16/07, Douglas A. Tutty <[EMAIL PROTECTED]> wrote: > > > This isn't a problem. > > The OP seems to think it is or he (she?) wouldn't waste his time > emailing the list or making an offer to a considerable amount of work to > fix it. Rather than just dissing him, why not enlighten us as to why That wasn't a diss, it was a statement of fact. A diss would be "This isn't a problem, you big fat slob." It's not a problem because the autotools tools are designed that way. You can't control what versions of what a particular autoconfiscated package will use. So an autotools upgrade doesn't affect previously installed versions. If you try ./configuring something that needs an older version it will tell you, so you can install the older version, set an env var (I think, it's been a while), and do the build. -g
Re: Tackilng multiple versions of autoconf
On Tue, Oct 16, 2007 at 11:50:52AM -0400, Douglas A. Tutty wrote: > On Tue, Oct 16, 2007 at 11:52:27AM +0100, Stuart Henderson wrote: > > On 2007/10/16 16:10, Amarendra Godbole wrote: > > > A peculiar thing I noticed with many ports is they need different > > > versions of > > > autoconf installed (set through the AUTOCONF_VERSION variable) - so in the > > > end, my system has 3 versions after a couple of port builds (2.13, 2.59, > > > and > > > 2.61). > > > > This isn't a problem. > > The OP seems to think it is or he (she?) wouldn't waste his time > emailing the list or making an offer to a considerable amount of work to > fix it. Rather than just dissing him, why not enlighten us as to why > its not a problem? > > Perhaps address the statement "... they _NEED_ different versions of > autoconf installed...". > > Doug. Fixing this is a waste of time. Autoconf itself is an issue. Actually a lot of engineering issues. Using it in the first place is a mistake. If you prefer, it's up to external projects to fix up their shit. KDE has stopped using the GNU auto* dreck, and I'm very happy for their switch to cmake. It's already enough of a headache to work around autoconf issues. Unifying them ? nope, not a chance. We have loads of better things to do. >From a practical point of view, each autoconf version is very small, and compiles/installs in just a fraction of the time it would take to `fix' ports to use a common autoconf.
Re: Tackilng multiple versions of autoconf
Hi, To be more reasonable (i suppose most ports using autotools in tree won't change their build scheme before earth blows itself, maybe because of autotools), i'd like to add my tiny-little p.o.v to this discussion : When upgrading a port, it costs little time to check that newest version still needs a particular AUTO*_VERSION, and remove the option if ports compiles with 'normal-latest' autotools version. But digging through whole tree to test each port would be a real waste of time. Landry On 10/16/07, Marc Espie <[EMAIL PROTECTED]> wrote: > On Tue, Oct 16, 2007 at 11:50:52AM -0400, Douglas A. Tutty wrote: > > On Tue, Oct 16, 2007 at 11:52:27AM +0100, Stuart Henderson wrote: > > > On 2007/10/16 16:10, Amarendra Godbole wrote: > > > > A peculiar thing I noticed with many ports is they need different > versions of > > > > autoconf installed (set through the AUTOCONF_VERSION variable) - so in > the > > > > end, my system has 3 versions after a couple of port builds (2.13, > 2.59, and > > > > 2.61). > > > > > > This isn't a problem. > > > > The OP seems to think it is or he (she?) wouldn't waste his time > > emailing the list or making an offer to a considerable amount of work to > > fix it. Rather than just dissing him, why not enlighten us as to why > > its not a problem? > > > > Perhaps address the statement "... they _NEED_ different versions of > > autoconf installed...". > > > > Doug. > > Fixing this is a waste of time. > > Autoconf itself is an issue. Actually a lot of engineering issues. > Using it in the first place is a mistake. > > If you prefer, it's up to external projects to fix up their shit. > > KDE has stopped using the GNU auto* dreck, and I'm very happy for their > switch to cmake. > > It's already enough of a headache to work around autoconf issues. Unifying > them ? nope, not a chance. > > We have loads of better things to do. > > From a practical point of view, each autoconf version is very small, and > compiles/installs in just a fraction of the time it would take to `fix' > ports to use a common autoconf.
Re: Tackilng multiple versions of autoconf
On Tue, Oct 16, 2007 at 07:45:24PM +0200, Landry Breuil wrote: > Hi, > > To be more reasonable (i suppose most ports using autotools in tree > won't change their build scheme before earth blows itself, maybe > because of autotools), i'd like to add my tiny-little p.o.v to this > discussion : > > When upgrading a port, it costs little time to check that newest > version still needs a particular AUTO*_VERSION, and remove the option > if ports compiles with 'normal-latest' autotools version. But digging > through whole tree to test each port would be a real waste of time. > > Landry > Nope, even this is a waste of time. If you use another version, you run the risk of running into hidden incompatibilities that we have to fix later
Re: Tackilng multiple versions of autoconf
Landry Breuil <[EMAIL PROTECTED]> wrote: > When upgrading a port, it costs little time to check that newest > version still needs a particular AUTO*_VERSION, and remove the option > if ports compiles with 'normal-latest' autotools version. Actually, I check the included configure script and use the same autoconf version. There is nothing to be gained in using the latest one. -- Christian "naddy" Weisgerber [EMAIL PROTECTED]
Re: Tackilng multiple versions of autoconf
On 2007/10/16 21:45, Marc Espie wrote: > On Tue, Oct 16, 2007 at 07:45:24PM +0200, Landry Breuil wrote: > > Hi, > > > > To be more reasonable (i suppose most ports using autotools in tree > > won't change their build scheme before earth blows itself, maybe > > because of autotools), i'd like to add my tiny-little p.o.v to this > > discussion : > > > > When upgrading a port, it costs little time to check that newest > > version still needs a particular AUTO*_VERSION, and remove the option > > if ports compiles with 'normal-latest' autotools version. But digging > > through whole tree to test each port would be a real waste of time. > > > > Landry > > > Nope, even this is a waste of time. > If you use another version, you run the risk of running into hidden > incompatibilities that we have to fix later $ locate patch-|grep configure|wc -l 618 ok, they won't _all_ be autoconf, but this gives you a rough idea how often autoconf users don't take account of making things work properly on other OS, which is rather the point of autoconf isn't it? with a lot of time and work testing and finding and fixing problems, the end result will be packages which work how they do already. i can think of better ways to use that time...
Re: Tackilng multiple versions of autoconf
On Tue, Oct 16, 2007 at 11:12:36PM +0100, Stuart Henderson wrote: > $ locate patch-|grep configure|wc -l > 618 > > ok, they won't _all_ be autoconf, but this gives you a rough idea how > often autoconf users don't take account of making things work properly > on other OS, which is rather the point of autoconf isn't it? heh, using autoconf gives a false sense of portability ;P -- [EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org
Re: Tackilng multiple versions of autoconf
On 10/17/07, Stuart Henderson <[EMAIL PROTECTED]> wrote: > On 2007/10/16 21:45, Marc Espie wrote: > > On Tue, Oct 16, 2007 at 07:45:24PM +0200, Landry Breuil wrote: > > > Hi, > > > > > > To be more reasonable (i suppose most ports using autotools in tree > > > won't change their build scheme before earth blows itself, maybe > > > because of autotools), i'd like to add my tiny-little p.o.v to this > > > discussion : > > > > > > When upgrading a port, it costs little time to check that newest > > > version still needs a particular AUTO*_VERSION, and remove the option > > > if ports compiles with 'normal-latest' autotools version. But digging > > > through whole tree to test each port would be a real waste of time. > > > > > > Landry > > > > > Nope, even this is a waste of time. > > If you use another version, you run the risk of running into hidden > > incompatibilities that we have to fix later > > $ locate patch-|grep configure|wc -l > 618 > > ok, they won't _all_ be autoconf, but this gives you a rough idea how > often autoconf users don't take account of making things work properly > on other OS, which is rather the point of autoconf isn't it? > > with a lot of time and work testing and finding and fixing problems, > the end result will be packages which work how they do already. i can > think of better ways to use that time... [...] Okay, after reading a lot of you, I guess it won't be wise to proceed with fixing autoconf versions in the ports. Being a newcomer to OpenBSD, and having some programming experience, I'd like to contribute back. Can you point me to some better ways to utilize that time? Thanks! Oh, and for those who were wondering, I am a "he". :-) Good day (evening) folks! -Amarendra -- Pune, India.
