Discussion: Replacing Configure with configure

Quoting Shawn (shawnw@speakeasy.org):
> I've been thinking about replacing the dist-based Configure script with 
> an autoconf-based configure.
> 
> Pros:
> 
> autoconf is the de facto standard configuration tool; people are 
> familiar with it.
> 
> autoconf itself is thus widely installed (Unlike dist, which I think 
> only us and maybe perl still use), which makes editing the configure 
> script easier for developers and patch writers.
> 
> Adding new tests is less work with autoconf than it is dist. It usually 
> takes just a line or two in configure.in, compared to making a whole new 
> file in the  configuration rule directory.
> 
> There's a bunch of un-needed tests in what we use now that can be 
> eliminated in the switch.
> 
> Cons:
> 
> It'll take some work; dist defines things like HAS_FOO, autoconf HAVE_FOO.
> 
> autoconf doesn't encourage cutesy little messages that give the 
> configure script personality.
> 
> Your thoughts?

I actually was having similar thoughts the other day. I was
reluctant to break a working system, though, so I didn't mention
it. :)

I didn't consider it very high priority, but I also didn't
think it would be too much work to make the switch.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Javelin@M*U*S*H, once Paul@DuneMUSH | Alan Schwartz <dunemush@pennmush.org>
   (mush.pennmush.org 4201)         |      PennMUSH Server Maintainer
=-------------------------------------------------------------------------=
   PennMUSH God's Guide: http://www.pennmush.org/~alansz/guide.html
        PennMUSH Source: http://ftp.pennmush.org/Source
     PennMUSH Community: http://community.pennmush.org
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

In message:  <20060311233700.1FCAAF003@tala.mede.uic.edu>
             Alan Schwartz <dunemush@pennmush.org> writes:
>Quoting Shawn (shawnw@speakeasy.org):
>> I've been thinking about replacing the dist-based Configure script with 
>> an autoconf-based configure.
>> 
>> Pros:
>> 
>> autoconf is the de facto standard configuration tool; people are 
>> familiar with it.
>> 
>> autoconf itself is thus widely installed (Unlike dist, which I think 
>> only us and maybe perl still use), which makes editing the configure 
>> script easier for developers and patch writers.
>> 
>> Adding new tests is less work with autoconf than it is dist. It usually 
>> takes just a line or two in configure.in, compared to making a whole new 
>> file in the  configuration rule directory.
>> 
>> There's a bunch of un-needed tests in what we use now that can be 
>> eliminated in the switch.
>> 
>> Cons:
>> 
>> It'll take some work; dist defines things like HAS_FOO, autoconf HAVE_FOO.
>> 
>> autoconf doesn't encourage cutesy little messages that give the 
>> configure script personality.
>> 
>> Your thoughts?
>
>I actually was having similar thoughts the other day. I was
>reluctant to break a working system, though, so I didn't mention
>it. :)
>
>I didn't consider it very high priority, but I also didn't
>think it would be too much work to make the switch.

My initial thought was that dist-based Configure is nicer in that
it has the interactive mode which is good for folks who aren't
familiar with what options are available... but then I realized
that I couldn't remember the last time I used anything but the
defaults.

Getting rid of the unused tests is definitely a good thing.

The obvious place where this hurts us is in the module for
subscribing/unsubscribing from the mailing list, but I have no
idea how effective that really is.

I'm OK with switching the configuration system.  HAS_FOO vs. HAVE_FOO
should just be a simple text substitution (perl one-liner), no?

- Alex

Shawn wrote:
> I've been thinking about replacing the dist-based Configure script with 
> an autoconf-based configure.
>
> Pros:
>
> autoconf is the de facto standard configuration tool; people are 
> familiar with it.
>
> autoconf itself is thus widely installed (Unlike dist, which I think 
> only us and maybe perl still use), which makes editing the configure 
> script easier for developers and patch writers.
>
> Adding new tests is less work with autoconf than it is dist. It usually 
> takes just a line or two in configure.in, compared to making a whole new 
> file in the  configuration rule directory.
>
> There's a bunch of un-needed tests in what we use now that can be 
> eliminated in the switch.
>
> Cons:
>
> It'll take some work; dist defines things like HAS_FOO, autoconf HAVE_FOO.
>
> autoconf doesn't encourage cutesy little messages that give the 
> configure script personality.
>
>
>
> Your thoughts?
>
>
>   
Spent some time last night playing with making a configure.in for Penn. 
The results are promising. I'll pick it back up when we have 1.8.3 out.

The autoconf SVN branch is now merged into devel as of rev 790. That branch can be considered closed; any more autoconf-related changes should be done in the mainline. You'll have to run configure after updating.