Ethereal-dev: Re: [Ethereal-dev] Do we still need 3 configure scripts?

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Joerg Mayer <jmayer@xxxxxxxxx>
Date: Wed, 10 Mar 2004 19:19:05 +0100
On Wed, Mar 10, 2004 at 05:16:09PM +0100, Biot Olivier wrote:
> Currently we have 3 sets of configure settings (top level directory, epan
> and wiretap). However, most of the settings are identical in the 3 sets.

I intend to merge ./configure.in and ./epan/configure.in eventually. There
were no real reasons to split them except we didn't know how to solve a certain
problem at that time :) I've asked the question of merging them before and
there seems to be significant opposition to merging the wiretap one. It looks
like some other project uses wiretap - including the wiretap specific configure.
If you want to merge epan into the toplevel, go ahead. As I mentioned before:
It's on my todo list, but not with a high priority.
Maybe we should clean up the api first so that nothing outside wiretap needs
to know anything about pcap.

> Running configure with the new autotools takes ages as compared to "earlier
> days", and sometimes changes in one auto-set are not reflected in the other
> ones.

a) we should/could move some common stuff into acinclude and b) are you using
--config-cache during configure? Here's what I use for configure:
CC=/opt/experimental/bin/gcc CFLAGS="-O3 -march=i686 -pipe" ./configure --with-extra-gcc-checks --config-cache --enable-gtk2 --enable-randpkt --enable-dftest

Yes, it has become slower and I exect this slowdown to be significantly
worse on cygwin than on native Unix/Linux.

> Is there still a valid reason to have (and maintain) these 3 sets?

See above.

> Additionally, maybe it is time that we start debugging/simplifying/rewriting
> them, as I have already seen many inconsistencies (e.g., --disable-usr-local
> will not work on the pcap tests as there is an explicit check on directories
> within /usr/local). I am starting to "feel at home" in those auto-stuff, but
> I'd like to find some reference on those tools... Anyone knows a good one?

Well, the info pages or
http://ftp.gnu.org/gnu/Manuals/automake-1.6.1/html_chapter/automake_12.html
Please note that some of these hacks are in there because of the many broken
setups that are out there. Other things really look like they should be
cleaned up.
As mentioned before: Go ahead :-) and expect some feedback of the form:
It worked before but not any more :-)

 ciao
    Jï¿œrg
-- 
Joerg Mayer                                           <jmayer@xxxxxxxxx>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.