httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rasmus Lerdorf <ras...@apache.org>
Subject Re: Pause to Consider
Date Fri, 26 Nov 1999 15:40:19 GMT
On Fri, 26 Nov 1999, Ralf S. Engelschall wrote:
> In article <Pine.WNT.4.21.9911260645100.-877023@lithium.jetpen.com> you wrote:
> 
> > [...]
> > The main problem with an approach like this, even if we are using a shared
> > config cache, is that running configure once for each module takes a long
> > long time.  
> 
> Sure, it will take longer. But I don't want to force each module to actually
> have an own configure script. Instead it certainly will be reasonable to
> bundle all standard modules again together and provide just one module for
> them, of course. That's ok. What I just want is that nevertheless this bundle
> of modules is again stand-alone, i.e. can be built inside and outside the
> source tree.  The major goal here is consistency through all modules.
> 
> > Being able to run configure once for a group of modules by
> > doing a 'cat *.m4' of the bundled modules is a very nice shortcut.  I
> > don't see any explicit limitation in that approach that stops us from
> > doing something similar to what you have in mind.  libapr, for example,
> > currently has its own configure script.  It isn't called from the
> > top-level configure yet, but that's just because Manoj hasn't done that
> > yet.  And if you look at the PHP 4 build mechanism which Manoj's stuff is
> > modelled after, you will see that the libzend and TSRM directories contain
> > their own configure scripts and are not part of the 'cat *.m4' process.
> >
> > For things that need to be built externally for some reason it makes sense
> > to give them their own configure script.  But why in the world would
> > mod_env, mod_imap (I really really hate that name), or mod_userdir need to
> > be compiled as external modules?  I just don't see it.  
> 
> Because if you treat all modules like external ones, you treat all
> modules equal. And this way your Makefiles can treat them equal, too.
> So my idea is that if they are treated all equal already for the config
> step, they can also easily treated equaly at the build and install step.
> And this way there is no real technical difference between distributed
> and third-party modules. That for already distributed modules it is a
> little bit too much separation may be, but I think it will not harm
> (even from a speed point of view, because one still can bundle together
> modules).

But if you just toss all the standard modules into a single directory then
you are no longer treating the modules the same.  Why can't each module
get its own directory.  If a config.m4 file exists in the directory it
will get merged into the main configure script at distribution time.  If a
module is added post-distribution, then the module should have its own
configure script.  A tool can be provided to module authors, call it apxs
if you like, that will take a standard config.m4 file and create the
appropriate standalone configure script.  This way every module is the
same from a module author's point of view.  All he has to do is create
config.m4, Makefile.am and config.h.stub.  To create a standalone module
distribution he would run the apxs tool on it to create the required
configure and config.h files.  

I guess the only real difference in our approach here is that I'd like to
see each module split up into its own subdir while you are advocating
having a single directory where all the standard modules and mushed
together and share a common standalone configure script.  I'd like to
separate each module's configure needs and at distribution time generate
the global configure script.  I still maintain that this approach meets
your goal of making each and every module look the same, whether they be
internal or external, better than your approach.

-Rasmus


Mime
View raw message