Greg Stein wrote:
> One of APR's goals is to be usable within applications (such as SVN). If the
> configuration isn't correct -- if it can't be configured within an app --
> then it can/will/must be changed.
> And the happy part, of course, is that I have the commit privs to do that.
> We just need to figure out the "correct" mechanism.
> It sounds like we might
> be getting somewhat close to a definition of what is really needed.
I'd say there are several classes of options:
(1) CPP flags (-I, -D, ...) Should be private
(2) Debugging (-W, -O, -g, ...) May be shared between modules
(3) Architecture (threads, alignment) Must be shared
(4) Code generation (-fPIC, -shared) May be shared
I realize the list is not complete and that these classes overlap a bit,
but I'm sure that won't cause problems in specific cases.
So, looking at this list: (1) is no problem, each module will take care
of it; (2) is also best solved in each module; (4) should probably be
enforced by the top-level configure for all modules.
Right now only threading falls into (3), and APR does a very good job of
finding the right combination of options (IIRC, it's not limited to using
pthreads, which may be a good thing). So APR's tests should either be
factored out into a separate acinclude file and reused by the top-level
configure, or APR's configure should export THREAD_CFLAGS for use by the
(I see you already included apr_common.m4 into the top-level configure.
Although the threading stuff is not complete there, I feel that's the
right solution -- especially if we can share config.cache between
modules so that we don't have to repeat those tests.)
Branko Čibej <email@example.com>
HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia
voice: (+386 1) 586 53 49 fax: (+386 1) 586 52 70
Received on Sat Oct 21 14:36:08 2006