<Pine.SOC.4.60.0507272342200.11359@xxxxxxxxxxxxxxxxxxxxxxx>Bob Friesenhahn writes: >On Wed, 27 Jul 2005, Noah Misch wrote: > >> On Tue, Jul 26, 2005 at 02:57:29PM -0400, tom fogal wrote: >>> Of course, the user has the option of specifying >>> LDFLAGS="/opt/local/lib" (or whatever) on their ./configure line, and >>> then the configure script finishes. I am of the opinion (and correct me >>> if I'm wrong) that unless the user jumped through special hoops when >>> compiling/installing software, they should not have to jump through >>> special hoops for other software to utilize that install. Arguably >> >> The portable way to configure a package that uses another package installed with >> --prefix=$other is `./configure CPPFLAGS=-I$other/include LDFLAGS=-L$other/lib'. >> >> Perhaps INSTALL should document that invocation pattern. Even so, the need is >> common enough to justify providing a shorthand. I do have a solution in mind. >> I hope to be able to contribute it real soon now. > >It is easy for a configure script to extend CPPFLAGS and LDFLAGS >itself based on the prefix but this can cause problems for the user >since then the user loses control over the header and linking search >path ordering. It is important to ensure that the person doing the >install retains control. Well it sounds like there is no good solution to this then =( I could try adding -I and -L directories, and make sure they always go at the end of whatever the user specifies. Can I make the assumption that all compilers will search dir1 before dir2 when given 'cc -Idir1 -Idir2'? Of course, this also leaves some users who have multiple copies installed to believe my script found the correct one, and unwittingly compile with the wrong library. Also it means I have to keep on top of where different packagers install things to, which seems like a lot of work / effort on the part of a package maintainer. Fortunately I've just noticed that gsl comes with a 'gsl-config' script. This helps me find directories, but with multiple GSL libraries installed I still could run into the issue of 'choosing' the wrong gsl-config script, and thus forcing a particular version of the library on my users. Maybe I could add an AC_ARG_WITH an option to specify the gsl-config path... Well it sounds like I have a workable solution to my current issue, but it relies on the library packager of the library I am using being 'good' and setting up a pkgconfig or <pkg>-config script. Perhaps I should be asking / moving this thread to the libtool mailing list, but is there any way we could have some part of the autotools suite automagically generate a script when it sees a library is being built? -tom _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
