On Fri, Jul 14, 2000 at 11:43:16PM -0500, Karl Fogel wrote:
> Zack Weinberg <email@example.com> writes:
> > ... so what needs to be done? I have to confess I don't see much that
> > -needs- autoconf to do anything for it, since all the icky stuff is
> > being dealt with in apr and/or glib.
> Folks, Zack's got a point. Part of the reason we have apr (glib is
> probably going away soon) is to isolate a lot of the portability
> issues into one already-written library. I sort of started
> autoconfiscating out of instinct... but now that you mention it, maybe
> we don't *need* to do it at all.
It is probably still useful for things like finding the compiler and
setting up installation paths. But I am firmly of the belief that the
less you put in your configure script, the better.
One problem we'll have to solve is shared library generation. A trick
I wanted to try at my former job was beating the magic switches out of
the Perl installation. Watch:
$ perl -V:cc -V:cccdlflags -V:lddlflags
That's almost all the information you need. The only other bit is how
you set the soname, and that is a relatively simple autoconf test.
(I don't know why there's a -L switch in there, but it's harmless.)
> > Is there any chance I can convince y'all to use hand-rolled
> > nonrecursive Makefiles instead of automake?
> Yes, on that there's a very big chance you could convince us :-).
> I've definitely had some second thoughts about the wisdom of going
> with automake in the last few days, and am now leaning toward
> hand-rolling Makefiles (or `Makefile.in's, as the case may be) instead
> of using automake. Whether they're recursive or not is a matter of
> style; you can have hand-rolled recursive Makefiles too.
I happen to be a big fan of nonrecursive make, but the subversion
layout - to the extent I understand it - could work okay with
recursion too. You've not got a hairy mess of cross-directory
dependencies the way gcc does.
Received on Sat Oct 21 14:36:05 2006