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 [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: cvs commit: apr-util/src/dbm Makefile.in apr_dbm.c
[EMAIL PROTECTED] 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 | [EMAIL PROTECTED] | 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
On Tue, Dec 05, 2000 at 07:03:19PM -0800, [EMAIL PROTECTED] 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/
Re: cvs commit: apr-util/src/dbm Makefile.in apr_dbm.c
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 [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: cvs commit: apr-util/src/dbm Makefile.in apr_dbm.c
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 [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
