[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: progress of Subversion autoconfiscation

From: Karl Fogel <kfogel_at_galois.collab.net>
Date: 2000-07-15 06:43:16 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.