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

Re: svn commit: rev 5251 - trunk

From: Justin Erenkrantz <jerenkrantz_at_apache.org>
Date: 2003-03-10 05:36:13 CET

--On Sunday, March 9, 2003 1:25 PM -0800 Greg Stein <gstein@lyra.org> wrote:

> But it isn't useful if APR's was configured with --disable-shared, yet you
> want that for SVN. Or vice-versa. There are other libtool configuration
> flags which you may want to use with SVN (e.g. --enable-all-static) that
> would *never* be done with APR.

All you do there is change the default options. libtool still allows you to
override the shared/non-shared options via the command-line (presuming that
libtool was configured with the least-restrictive options for that platform).

> And the user who is configuring SVN isn't going to really know about these
> dependencies.

That's not whom these options are meant for. It's meant for giving people who
know what they are doing a way to get out of the libtool madness. Currently,
there is no way to support platforms where GNU libtool doesn't work.

> I'm alright with using something like jlibtool as a substitute, but I don't
> think that we should ever tie our "libtool" configuration to another
> package's configuration.

Then, we should be relying upon passing the required flag ourselves where
necessary. Relying upon the fact that the user's preference for
shared/non-shared will be kept by libtool is harmful. libtool wasn't meant to
be customized per project. It's just been bastardized to behave like that.

It should always be perfectly legal to point at /usr/bin/libtool (where that's
the platform's GNU libtool) and have everything just work per our
configuration. IMHO, anything else is a bug. If that means we have to pass
in -static or -all-static to libtool explicitly (by picking up --enable-shared
or whatever), I think that is a good thing to start doing. But, expecting all
libtool's to magically understand that we want -static or -all-static without
telling it that at run-time seems a tad much.

>> +dnl Look for a C pre-processor
>> +AC_PROG_CPP
>> +
>> +dnl Look for an extended grep
>> +AC_PROG_EGREP
>
> What are these for? You didn't add anything that used these. Were we already
> using these features, but forget to do the AC_PROG_* thing?

Yes, the svn-apache.m4 macros were using AC_EGREP_CPP (line 36), but we were
relying on the AC_PROG_LIBTOOL having called these implicitly. When I took
out the AC_PROG_LIBTOOL call, configure started failing because $CPP and
$EGREP were not defined. We should have been calling them explicitly and I
called this out in the log for 5251. (Don't know how to have made it
clearer.) -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 10 05:36:50 2003

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.