You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Justin Erenkrantz <je...@apache.org> on 2002/09/13 19:36:31 UTC
[PROPOSAL] Create apr-build repository
Since we have a lot of files within APR that we want to share across
other projects to help support the build system, I think we should
create an apr-build repository that contains these files so that
other projects can check out these projects and have one unified
version of these files rather than copying them over from APR and
potentially getting them out-of-sync.
Namely the files we would start with would be:
apr-build/
autoconf/
PrintPath
apr_common.m4
config.guess
config.sub
find_apr.m4 (ambivalent about being in here, but perhaps)
get-version.sh
install.sh
rules.mk.in (perhaps, but I'm not sure)
aplibtool/
aplibtool.c
This may also provide a proper resting place for my jlibtool.c
(which as Fred points out needs autoconf scripts of its own to
properly detect the OS).
I think we could rely on CVS modules to autocheckout the files,
but I'm not exactly clear how that would work.
Thoughts? -- justin
Re: [PROPOSAL] Create apr-build repository
Posted by "Roy T. Fielding" <fi...@apache.org>.
> It isn't directly related to autoconf. We wanted to share autoconf and
> other
> build scripts. That is the *core* reason why the projects are not
> self-supporting.
Not only share them -- we wanted to avoid running them 5 times for each
build of httpd. We only need to run them once and share the results.
> But since m4 doesn't have flexible include processing, then we end up
> with a
> lot tighter dependency than we would normally have.
Or we could change buildconf back to the procedure of copying all of
the m4 files into one local include file and only including that one file
within configure.in. I changed that because it interfered with bug fixing,
but that's life.
We would still need to install the build files with apr and we should have
a parameter on buildconf that tells it which apr to pick up.
I do not think it belongs in a separate apr-build repository.
....Roy
Re: [PROPOSAL] Create apr-build repository
Posted by Greg Stein <gs...@lyra.org>.
It isn't directly related to autoconf. We wanted to share autoconf and other
build scripts. That is the *core* reason why the projects are not
self-supporting.
But since m4 doesn't have flexible include processing, then we end up with a
lot tighter dependency than we would normally have.
Cheers,
-g
On Fri, Sep 13, 2002 at 02:52:14PM -0400, Ryan Bloom wrote:
>
> We got into this mess by using autoconf. Unfortunately, there is nothing
> better than Autoconf...yet... :-)
>
> Ryan
>
> On Fri, 13 Sep 2002, David Reid wrote:
>
> > Huh? Oh, OK I see now. How in the hell did we get ourselves in this mess? If
> > these are projects they should be self supporting. I'm really not in favour
> > of having a sub directory. Nor do I really want so many copies of these
> > things on my machine!
>...
--
Greg Stein, http://www.lyra.org/
Re: [PROPOSAL] Create apr-build repository
Posted by Ryan Bloom <rb...@ntrnet.net>.
We got into this mess by using autoconf. Unfortunately, there is nothing
better than Autoconf...yet... :-)
Ryan
On Fri, 13 Sep 2002, David Reid wrote:
> Huh? Oh, OK I see now. How in the hell did we get ourselves in this mess? If
> these are projects they should be self supporting. I'm really not in favour
> of having a sub directory. Nor do I really want so many copies of these
> things on my machine!
>
> Sigh...
>
> david
>
> > On Fri, Sep 13, 2002 at 07:19:25PM +0100, David Reid wrote:
> > > OK, but let's assume that apr is needed for these. I mean they are based
> on
> > > apr (apr as in the original plain old boring apr library) right? Then I
> > > guess what I don't understand is why we don't simply have the packages
> use a
> > > script that tells them the location and then just use them...
> >
> > No, they're not built from APR - they are simply m4 macros or
> > shell scripts that autoconf requires. We could expand it to include
> > other functionality, but the key here is to support autoconf.
> >
> > > The script is built by apr and installed, then either used from an
> install
> > > or from the apr dir if we're in a cvs type environment...
> >
> > Nope. Can't do that as autoconf needs these files at both generation
> > and invocation of the configure scripts.
> >
> > That precludes any 'oh, hey, look they are here' magic. They really
> > do have to be in the local repository or hardcoded paths. -- justin
> >
>
--
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------
Re: [PROPOSAL] Create apr-build repository
Posted by David Reid <dr...@jetnet.co.uk>.
Huh? Oh, OK I see now. How in the hell did we get ourselves in this mess? If
these are projects they should be self supporting. I'm really not in favour
of having a sub directory. Nor do I really want so many copies of these
things on my machine!
Sigh...
david
> On Fri, Sep 13, 2002 at 07:19:25PM +0100, David Reid wrote:
> > OK, but let's assume that apr is needed for these. I mean they are based
on
> > apr (apr as in the original plain old boring apr library) right? Then I
> > guess what I don't understand is why we don't simply have the packages
use a
> > script that tells them the location and then just use them...
>
> No, they're not built from APR - they are simply m4 macros or
> shell scripts that autoconf requires. We could expand it to include
> other functionality, but the key here is to support autoconf.
>
> > The script is built by apr and installed, then either used from an
install
> > or from the apr dir if we're in a cvs type environment...
>
> Nope. Can't do that as autoconf needs these files at both generation
> and invocation of the configure scripts.
>
> That precludes any 'oh, hey, look they are here' magic. They really
> do have to be in the local repository or hardcoded paths. -- justin
>
Re: [PROPOSAL] Create apr-build repository
Posted by Justin Erenkrantz <je...@apache.org>.
On Fri, Sep 13, 2002 at 07:19:25PM +0100, David Reid wrote:
> OK, but let's assume that apr is needed for these. I mean they are based on
> apr (apr as in the original plain old boring apr library) right? Then I
> guess what I don't understand is why we don't simply have the packages use a
> script that tells them the location and then just use them...
No, they're not built from APR - they are simply m4 macros or
shell scripts that autoconf requires. We could expand it to include
other functionality, but the key here is to support autoconf.
> The script is built by apr and installed, then either used from an install
> or from the apr dir if we're in a cvs type environment...
Nope. Can't do that as autoconf needs these files at both generation
and invocation of the configure scripts.
That precludes any 'oh, hey, look they are here' magic. They really
do have to be in the local repository or hardcoded paths. -- justin
Re: [PROPOSAL] Create apr-build repository
Posted by David Reid <dr...@jetnet.co.uk>.
OK, but let's assume that apr is needed for these. I mean they are based on
apr (apr as in the original plain old boring apr library) right? Then I
guess what I don't understand is why we don't simply have the packages use a
script that tells them the location and then just use them...
The script is built by apr and installed, then either used from an install
or from the apr dir if we're in a cvs type environment...
Don't really think adding yet another cvs repository is going to cure the
basic problem you've been outlining, just add yet another place for it to
all go bang.
david
----- Original Message -----
From: "Aaron Bannert" <aa...@clove.org>
To: "APR Development List" <de...@apr.apache.org>
Sent: Friday, September 13, 2002 7:09 PM
Subject: Re: [PROPOSAL] Create apr-build repository
> On Fri, Sep 13, 2002 at 06:44:19PM +0100, David Reid wrote:
> > Not sure I like this. Shouldn't the other project just use the apr files
> > rather than copying their own versions?
> >
> > More context please...
>
> There's a code-redundancy problem that is sortof being caused by a
> build dependency problem.
>
> For example, flood uses some of the .m4 macros from APR's source
> directory. Since we don't want to go looking for those things in our
> buildconf script, we just stick them in flood's CVS and then include
> them in our configure.in file. This causes code duplication and forks
> our version from any updates to the real APR version.
>
> Ideally this apr-build package would simply install the .m4 and .in
> files in some directory, and provide a apr-build-config script that
> can be optionally called to discover where those .m4 and .in files were
> actually installed. That way it could be called straight from buildconf
> to find the m4 files, copy them to the right place, and then flood's
> configure is happy w/o having to maintain our own macro files.
>
> There are still a couple of gray spots in that scenario, in my mind,
> that need to be worked out, but this is the direction I'm looking.
>
>
> An alternative solution would be to have APR simply install those macro
> files somewhere so other projects could use them...
>
> -aaron
>
Re: [PROPOSAL] Create apr-build repository
Posted by Aaron Bannert <aa...@clove.org>.
On Fri, Sep 13, 2002 at 06:44:19PM +0100, David Reid wrote:
> Not sure I like this. Shouldn't the other project just use the apr files
> rather than copying their own versions?
>
> More context please...
There's a code-redundancy problem that is sortof being caused by a
build dependency problem.
For example, flood uses some of the .m4 macros from APR's source
directory. Since we don't want to go looking for those things in our
buildconf script, we just stick them in flood's CVS and then include
them in our configure.in file. This causes code duplication and forks
our version from any updates to the real APR version.
Ideally this apr-build package would simply install the .m4 and .in
files in some directory, and provide a apr-build-config script that
can be optionally called to discover where those .m4 and .in files were
actually installed. That way it could be called straight from buildconf
to find the m4 files, copy them to the right place, and then flood's
configure is happy w/o having to maintain our own macro files.
There are still a couple of gray spots in that scenario, in my mind,
that need to be worked out, but this is the direction I'm looking.
An alternative solution would be to have APR simply install those macro
files somewhere so other projects could use them...
-aaron
Re: [PROPOSAL] Create apr-build repository
Posted by Justin Erenkrantz <je...@apache.org>.
On Fri, Sep 13, 2002 at 06:44:19PM +0100, David Reid wrote:
> Not sure I like this. Shouldn't the other project just use the apr files
> rather than copying their own versions?
Nope, that's the problem! apr-util needs to be able to build on its
own rather than relying upon apr being in ../apr.
As Garrett pointed out, the apr-util release is a dud packaging-wise,
because ../apr isn't available at configure-time.
So, these projects *must* have their own local copies of these
particular files. -- justin
Re: [PROPOSAL] Create apr-build repository
Posted by Justin Erenkrantz <je...@apache.org>.
On Fri, Sep 13, 2002 at 06:54:08PM +0100, David Reid wrote:
> OK, this doesn't seem to gel with my original or current view of apr-util,
> but then you guys have been adding all sorts of stuff in there so maybe it's
> place in the world has altered. If that's the case then I'm still not sure
> doing something like this is the correct way of doing it.
Any suggestions then? This has a wider scope than just apr-util.
apr-util, httpd-2.0, serf, flood, SVN all require some subset of
those files I listed that are only in APR.
For serf, flood, and SVN, they copy those files into their local
repository. For apr-util and httpd-2.0, they require apr to be in a
very specific location. I think we can do better. -- justin
Re: [PROPOSAL] Create apr-build repository
Posted by David Reid <dr...@jetnet.co.uk>.
OK, this doesn't seem to gel with my original or current view of apr-util,
but then you guys have been adding all sorts of stuff in there so maybe it's
place in the world has altered. If that's the case then I'm still not sure
doing something like this is the correct way of doing it.
david
> David Reid wrote:
> > Not sure I like this. Shouldn't the other project just use the apr files
> > rather than copying their own versions?
> >
> > More context please...
>
> if the projects use the apr files, then you end up with the situation
> that apr-util is in now, where one cannot actually build apr-util
> separately from apr. even if apr is installed on the system already,
> you actually have to have the apr directory tree sitting next to the
> apr-util directory tree or you can't even run configure.
>
> since apr-util is supposed to be a separate project, this seems like a
> pretty bad situation to me. it would be one thing if apr installed the
> files on the system, where the build process of the other projects could
> find and use it, but requiring you to actually have the source tree
> there seems a bit much.
>
> -garrett
>
>
Re: [PROPOSAL] Create apr-build repository
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
David Reid wrote:
> Not sure I like this. Shouldn't the other project just use the apr files
> rather than copying their own versions?
>
> More context please...
if the projects use the apr files, then you end up with the situation
that apr-util is in now, where one cannot actually build apr-util
separately from apr. even if apr is installed on the system already,
you actually have to have the apr directory tree sitting next to the
apr-util directory tree or you can't even run configure.
since apr-util is supposed to be a separate project, this seems like a
pretty bad situation to me. it would be one thing if apr installed the
files on the system, where the build process of the other projects could
find and use it, but requiring you to actually have the source tree
there seems a bit much.
-garrett
Re: [PROPOSAL] Create apr-build repository
Posted by David Reid <dr...@jetnet.co.uk>.
Not sure I like this. Shouldn't the other project just use the apr files
rather than copying their own versions?
More context please...
david
> Since we have a lot of files within APR that we want to share across
> other projects to help support the build system, I think we should
> create an apr-build repository that contains these files so that
> other projects can check out these projects and have one unified
> version of these files rather than copying them over from APR and
> potentially getting them out-of-sync.
>
> Namely the files we would start with would be:
>
> apr-build/
> autoconf/
> PrintPath
> apr_common.m4
> config.guess
> config.sub
> find_apr.m4 (ambivalent about being in here, but perhaps)
> get-version.sh
> install.sh
> rules.mk.in (perhaps, but I'm not sure)
> aplibtool/
> aplibtool.c
>
> This may also provide a proper resting place for my jlibtool.c
> (which as Fred points out needs autoconf scripts of its own to
> properly detect the OS).
>
> I think we could rely on CVS modules to autocheckout the files,
> but I'm not exactly clear how that would work.
>
> Thoughts? -- justin
>
Re: [PROPOSAL] Create apr-build repository
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Sep 13, 2002 at 11:06:45AM -0700, Justin Erenkrantz wrote:
> On Fri, Sep 13, 2002 at 11:02:48AM -0700, Aaron Bannert wrote:
> > Sounds good, here's another suggestion:
> >
> > apr-build/
> > autoconf/
> > *.m4 and related
> > bin/
> > *.sh, binaries, and related
> > build/
> > *.in
> > ...and so on
>
> That's not a bad idea, I guess. But, the problem is that autoconf
> requires install.sh to be in the same dir as config.guess and
> config.sub. So, splitting it out like that might not work too well.
Well, we can keep the install.sh over there for autoconf support, but I'd
recommend that any other stuff remain in bin/
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [PROPOSAL] Create apr-build repository
Posted by Justin Erenkrantz <je...@apache.org>.
On Fri, Sep 13, 2002 at 11:02:48AM -0700, Aaron Bannert wrote:
> Sounds good, here's another suggestion:
>
> apr-build/
> autoconf/
> *.m4 and related
> bin/
> *.sh, binaries, and related
> build/
> *.in
> ...and so on
That's not a bad idea, I guess. But, the problem is that autoconf
requires install.sh to be in the same dir as config.guess and
config.sub. So, splitting it out like that might not work too well.
> That would be my preference, but there may be issues with the GPL that
> we need to figure out (you know best wherefrom this was derived).
Nah, jlibtool was derived from aplibtool.c in APR's repository.
No GPL code... -- justin
Re: [PROPOSAL] Create apr-build repository
Posted by Aaron Bannert <aa...@clove.org>.
On Fri, Sep 13, 2002 at 10:36:31AM -0700, Justin Erenkrantz wrote:
> Since we have a lot of files within APR that we want to share across
> other projects to help support the build system, I think we should
> create an apr-build repository that contains these files so that
> other projects can check out these projects and have one unified
> version of these files rather than copying them over from APR and
> potentially getting them out-of-sync.
>
> Namely the files we would start with would be:
>
> apr-build/
> autoconf/
> PrintPath
> apr_common.m4
> config.guess
> config.sub
> find_apr.m4 (ambivalent about being in here, but perhaps)
> get-version.sh
> install.sh
> rules.mk.in (perhaps, but I'm not sure)
> aplibtool/
> aplibtool.c
Sounds good, here's another suggestion:
apr-build/
autoconf/
*.m4 and related
bin/
*.sh, binaries, and related
build/
*.in
...and so on
> This may also provide a proper resting place for my jlibtool.c
> (which as Fred points out needs autoconf scripts of its own to
> properly detect the OS).
That would be my preference, but there may be issues with the GPL that
we need to figure out (you know best wherefrom this was derived).
> I think we could rely on CVS modules to autocheckout the files,
> but I'm not exactly clear how that would work.
>
> Thoughts? -- justin
+1
-aaron