You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by rb...@covalent.net on 2000/12/06 04:03:19 UTC
Re: cvs commit: apr-util/src/dbm Makefile.in apr_dbm.c
> *) move building of aprutil.exports into the top-level Makefile so that we
> can use APR's directory (rather than needing to pass it to buildconf.sh)
You can't do this. We need this file when running buildconf in Apache,
and it doesn't make any sense to do this each time we build apr-utils,
because this is not a very fast operation, especially once we add more
header files.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apr-util/src/dbm Makefile.in apr_dbm.c
Posted by rb...@covalent.net.
> > > *) move building of aprutil.exports into the top-level Makefile so that we
> > > can use APR's directory (rather than needing to pass it to buildconf.sh)
> >
> > You can't do this. We need this file when running buildconf in Apache,
> > and it doesn't make any sense to do this each time we build apr-utils,
> > because this is not a very fast operation, especially once we add more
> > header files.
>
> I guess this is what keeps aprutil.exports from being available at the
> right time
Yep.
> (build/buildexports.sh: srclib/apr-util/aprutil.exports: No such file or directory)
>
> which leads in some sick way to the APR exports list being expanded
> twice in exports.c which keeps exports.c from compiling properly?
The APR exports list is expanded twice, because we never replace stdin in
buildexports.sh. I guess this could be fixed temporarily by closing stdin
at the end of the for loop. The real fix is to back out the change
however.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apr-util/src/dbm Makefile.in apr_dbm.c
Posted by rb...@covalent.net.
> > > *) move building of aprutil.exports into the top-level Makefile so that we
> > > can use APR's directory (rather than needing to pass it to buildconf.sh)
> >
> > You can't do this. We need this file when running buildconf in Apache,
> > and it doesn't make any sense to do this each time we build apr-utils,
> > because this is not a very fast operation, especially once we add more
> > header files.
>
> I guess this is what keeps aprutil.exports from being available at the
> right time
Yep.
> (build/buildexports.sh: srclib/apr-util/aprutil.exports: No such file or directory)
>
> which leads in some sick way to the APR exports list being expanded
> twice in exports.c which keeps exports.c from compiling properly?
The APR exports list is expanded twice, because we never replace stdin in
buildexports.sh. I guess this could be fixed temporarily by closing stdin
at the end of the for loop. The real fix is to back out the change
however.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apr-util/src/dbm Makefile.in apr_dbm.c
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@covalent.net writes:
> > *) move building of aprutil.exports into the top-level Makefile so that we
> > can use APR's directory (rather than needing to pass it to buildconf.sh)
>
> You can't do this. We need this file when running buildconf in Apache,
> and it doesn't make any sense to do this each time we build apr-utils,
> because this is not a very fast operation, especially once we add more
> header files.
I guess this is what keeps aprutil.exports from being available at the
right time
(build/buildexports.sh: srclib/apr-util/aprutil.exports: No such file or directory)
which leads in some sick way to the APR exports list being expanded
twice in exports.c which keeps exports.c from compiling properly?
Cool...
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apr-util/src/dbm Makefile.in apr_dbm.c
Posted by Jeff Trawick <tr...@bellsouth.net>.
rbb@covalent.net writes:
> > *) move building of aprutil.exports into the top-level Makefile so that we
> > can use APR's directory (rather than needing to pass it to buildconf.sh)
>
> You can't do this. We need this file when running buildconf in Apache,
> and it doesn't make any sense to do this each time we build apr-utils,
> because this is not a very fast operation, especially once we add more
> header files.
I guess this is what keeps aprutil.exports from being available at the
right time
(build/buildexports.sh: srclib/apr-util/aprutil.exports: No such file or directory)
which leads in some sick way to the APR exports list being expanded
twice in exports.c which keeps exports.c from compiling properly?
Cool...
--
Jeff Trawick | trawickj@bellsouth.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
Re: cvs commit: apr-util/src/dbm Makefile.in apr_dbm.c
Posted by rb...@covalent.net.
> > By moving it into the Makefile, we have access to the APR directory. The
> > parameter to buildconf.sh is a bit strange... our other buildconf scripts
> > don't do it (nor does autogen.sh in SVN). In some cases, APR can be found by
> > the configure script automatically, so nobody would need to pass a parameter
> > at any time to say where APR is located.
>
> I believe this should all be done at buildconf time, not configure
> time. Move all the checks into buildconf for specifying library
> directories. Trying to configure a package without having all the
> libraries installed just doesn't work.
I should also mention here that by putting this into the buildconf stage,
we are actually helping ourselves, because it means that we can reliably
run APR and APR-util's ./buildconf scripts from Apache and Subversion,
even if they do not live in the standard locations in the tree. Try doing
that now, and you will find that you will need either a symbolic link or a
full copy of APR and APR-util in the correct location during the buildconf
stage.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apr-util/src/dbm Makefile.in apr_dbm.c
Posted by rb...@covalent.net.
> The file will only be built once. If you do a "make extraclean", then it
> will need to be built again. If the thing is built once, then it shouldn't
> really matter whether it is built at "buildconf.sh" or "make" time.
But it breaks the first time you try to configure Apache. That's no
good. Plus, by adding the apr directory to the buildconf stage, we can
remove it from the ./configure stage. apr-utils is useless without APR,
so we should be specifying its location during buildconf. We should do
the same for Apache, but that is a much bigger change, and I haven't
gotten around to it yet. That would let us build Apache with APR's that
do not live in the build tree.
> By moving it into the Makefile, we have access to the APR directory. The
> parameter to buildconf.sh is a bit strange... our other buildconf scripts
> don't do it (nor does autogen.sh in SVN). In some cases, APR can be found by
> the configure script automatically, so nobody would need to pass a parameter
> at any time to say where APR is located.
I believe this should all be done at buildconf time, not configure
time. Move all the checks into buildconf for specifying library
directories. Trying to configure a package without having all the
libraries installed just doesn't work.
> Regarding Apache: why isn't exports.c built at "make" time, too? I don't see
> a need for that to be done at buildconf time either.
Because we only want to do it once. I did move it into the make stage on
my own tree at one point, and it made the build far too slow without any
feedback. I realize we would only do it when things have changed, but
we are still forcing people who download a tarball to rebuild their export
list, when they aren't changing anything the first time. The speed may
have gotten better with the change to awk for buildexports, I really don't
know.
> I'm more than happy to go punch Apache to move the construction of exports.c
> into "make" time rather than buildconf time. By doing it at make time, we
> can also create dependencies on the APR and APRUTIL export files. Thus, if
> we are doing some coding in APR(UTIL) and change the exports, Apache will
> automatically update (rather than needing to wait for somebody to run
> buildconf again).
It doesn't matter if Apache re-builds it's exports when apr and apr-util
rebuild their .exports file, because they never do that. The thing is
that we would need to re-build the .exports file anytime ANY .h file was
changed, and I don't know about the other developers, but I change header
files all the time, and usually not in a way that breaks the exports
list. In other words, even if we change the call to buildexports.sh to
put it into a makefile, it won't change anything, because we never update
the .exports file except for at buildconf time.
This could move into the configure phase, if you can figure out how to get
autoconf to do all this stuff at the correct time. Regardless, what we
have now is broken and needs to be fixed ASAP.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apr-util/src/dbm Makefile.in apr_dbm.c
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Dec 05, 2000 at 07:03:19PM -0800, rbb@covalent.net wrote:
>
> > *) move building of aprutil.exports into the top-level Makefile so that we
> > can use APR's directory (rather than needing to pass it to buildconf.sh)
>
> You can't do this. We need this file when running buildconf in Apache,
> and it doesn't make any sense to do this each time we build apr-utils,
> because this is not a very fast operation, especially once we add more
> header files.
The file will only be built once. If you do a "make extraclean", then it
will need to be built again. If the thing is built once, then it shouldn't
really matter whether it is built at "buildconf.sh" or "make" time.
By moving it into the Makefile, we have access to the APR directory. The
parameter to buildconf.sh is a bit strange... our other buildconf scripts
don't do it (nor does autogen.sh in SVN). In some cases, APR can be found by
the configure script automatically, so nobody would need to pass a parameter
at any time to say where APR is located.
Regarding Apache: why isn't exports.c built at "make" time, too? I don't see
a need for that to be done at buildconf time either.
I'm more than happy to go punch Apache to move the construction of exports.c
into "make" time rather than buildconf time. By doing it at make time, we
can also create dependencies on the APR and APRUTIL export files. Thus, if
we are doing some coding in APR(UTIL) and change the exports, Apache will
automatically update (rather than needing to wait for somebody to run
buildconf again).
Your thoughts?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/