Right. One of the things I like most about configure scripts
generated by autoconf, is that I can do something like this:
tar zxvvf abi-0.5.4-src.tar.gz
mkdir abi-build
cd abi-build
../abi-0.5.4/configure
make
Ok, that this might seem like a cute trick, but not terribly useful,
but once you get used to it, you get to like it a lot. It means that
you can build binaries for multiple architectures from the same source
tree and it means that you can go in and patch the source tree and
then do a 'diff -urN' against the original contents of the tarfile,
and you don't get a whole lot of diff telling you that you have
created .o files and so on.
> in the next week or so, i'll be looking into putting together
> automated build systems as part of our preparation for releasing
> binaries with the 0.7.0 release. i'll try to keep this in mind
> as i'm working on that.
Ok, that's fine. If you can get the above behavior without autoconf,
that's good enough for me.
> as for using autoconf to let us behave like most other packages,
> we really haven't needed much of the stuff that it provides. and
> there is that Win32, MacOS, BeOS, etc. port to contend with. about
> the only system sniffing that we have is the uname hacks in
> src/config/abi_defs.
Right. BeOS should be able to cope with autoconf generated scripts
without many problems. Win32, however, is another story. I've tried
to get autoconf to generate scripts which work well with the Cygwin
tools before, and it is a huge pain. Most of the problem is that
Win32 really wants executable files to end in .EXE and this really
confuses the autoconf tests which build and test code to check
capabilities. I ended up writing a build system in Perl instead of
trying to convert the autoconf scripts from the package I was trying
to port to Win32. So, yeah, that is a very good argument against
using autoconf. I am MacOS ignorant, but I'd guess there would be as
many or more problems getting autoconf scripts to work there.
> we've had lots of requests for it (2 or 3 this week it seems),
> but to date, i'm not yet convinced we need it.
Yeah, you don't need it. But it is nice when you are limiting
yourself to a *nix environment. If it ever comes to the point that
the *nix Makefiles need to be seperated from the other makefiles for
some other reason, then I'd feel strongly that you should use
autoconf. But as long as the Makefiles are unified across platforms,
it is probably much more hassle than it is worth.
> [i've rewritten this paragraph 3 times and i still don't know how
> to say this with out sounding condescending or harsh, and this is
> definetly not directed at you personally but to the whole list....]
>
> our true goal or the true measure of our success [AbiWord and the
> greater Open Source movement in general] is not whether it builds
> with "./configure;make;make install" but whether we can get it
> installed onto the "Church Secretary's" computer and get the weekly
> bulletin printed with it.... yes, a more spiffy makefile would be
> cool, but i'm shooting for a bigger form of cool..... :-) :-) :-)
I absolutely agree with this sentiment. But getting installed on the
chruch secretary's machine and having a nice environment to hack code
in aren't mutually exclusive. We *can* have both. The important thing
is not to be satisifed with only having a nice word processor for
geekier among us.
-- Matt Kimball mkimball@xmission.com