Zack Weinberg <zack@wolery.cumb.org> 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.
Hmm.
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.
Wow. Hmm.
I'm not sure apr/ handles *all* our portability problems, but it
certainly seems plausible that it could. And if it doesn't, there's
always the possibility that we could [re]write things so that it does.
Thoughts from others? Am I missing some big loophole here?
> 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.
There shouldn't be a final decision on either of these until Jim
Blandy has had a chance to speak up. He's handled a _lot_ of
portability issues in his time, has a lot of experience with autoconf,
and some with automake.
Jim?
Received on Sat Oct 21 14:36:05 2006