Re: cvs commit: apr/user/unix .cvsignore Makefile.in
[Note: My connectivity is quite limited currently.. ] Somewhat... but it does mean that we'd be looking down into .libs for the libraries to put into NON_LIBTOOL_LIBS. Not sure what I think about that one... (reaching into .libs is the basic question: do we or don't we?) Am I correct in assuming that the point of those variables is to export a list of libraries which are build by APR and which basically form the APR library? Or are those variables supposed to additionally contain external dependencies (i.e. on system libraries) for the APR library? - Sascha
Re: cvs commit: apr/user/unix .cvsignore Makefile.in
It works for me. I only have two mild concerns: 1) APR's use of .la files when the user doesn't use libtool (noted above) 2) APRVARS.in using variables not in the APR namespace. See apr-util's export_vars.sh.in for what I think is the Right Way (and how it is used in Apache's configure.in). By using unprotected names in APRVARS, we might stomp on the user's vars. I've got no immediate answer for (1), and (2) is just something that has been in mind for a while. I'll get around to it at some point, probably after JimJag's flag revision stuff. Can I suggest a possible solution for 1, and agree 100% with 2? The possible solution, is to use two variables, LIBTOOL_LIBS, and NON_LIBTOOL_LIBS. These names are probably wrong, call they what you want to. The idea is that if you use LIBTOOL, you have to add the libraries in LIBTOOL_LIBS, if not you have to use NON_LIBTOOL_LIBS. If you don't use libtool, you basically have to add the NON_LIBTOOL_LIBS to APR_LIBS. Does that make sense? Ryan ___ Ryan Bloom [EMAIL PROTECTED] 406 29th St. San Francisco, CA 94131 ---
Re: cvs commit: apr/user/unix .cvsignore Makefile.in
On Wed, Jan 10, 2001 at 09:22:30PM -0800, [EMAIL PROTECTED] wrote: It works for me. I only have two mild concerns: 1) APR's use of .la files when the user doesn't use libtool (noted above) 2) APRVARS.in using variables not in the APR namespace. See apr-util's export_vars.sh.in for what I think is the Right Way (and how it is used in Apache's configure.in). By using unprotected names in APRVARS, we might stomp on the user's vars. I've got no immediate answer for (1), and (2) is just something that has been in mind for a while. I'll get around to it at some point, probably after JimJag's flag revision stuff. Can I suggest a possible solution for 1, and agree 100% with 2? The possible solution, is to use two variables, LIBTOOL_LIBS, and NON_LIBTOOL_LIBS. These names are probably wrong, call they what you want to. The idea is that if you use LIBTOOL, you have to add the libraries in LIBTOOL_LIBS, if not you have to use NON_LIBTOOL_LIBS. If you don't use libtool, you basically have to add the NON_LIBTOOL_LIBS to APR_LIBS. Does that make sense? Somewhat... but it does mean that we'd be looking down into .libs for the libraries to put into NON_LIBTOOL_LIBS. Not sure what I think about that one... (reaching into .libs is the basic question: do we or don't we?) Sascha may have an idea here. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/user/unix .cvsignore Makefile.in
[EMAIL PROTECTED] writes: gstein 01/01/09 03:06:29 Libtool-ize APR. Index: Makefile.in === RCS file: /home/cvs/apr/shmem/unix/Makefile.in,v retrieving revision 1.14 retrieving revision 1.15 diff -u -u -r1.14 -r1.15 --- Makefile.in 2000/11/15 11:50:07 1.14 +++ Makefile.in 2001/01/09 11:06:15 1.15 ... + cp $(MM_OBJS) . Isn't this copying the wrong (or not enough) files? It currently copies just the .lo (timestamp) files. Maybe it should copy the .o files too. Later, libtool thinks these are the real files (I guess) and when building .libs/libapr.a it ends up creating the symbolic links (the ones that don't work with libtool 1.3.3) and putting these timestamp files in the archive. mm_malloc/mm_free/etc. are not in .libs/libapr.a. They are referenced, of course. -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
