Hi Tom,
* tom fogal wrote on Thu, Jun 23, 2005 at 07:11:20PM CEST:
> <20050623055800.GA4215@xxxxxxxxxxxxxxx>Ralf Wildenhues writes:
> >
> >Ouch. Don't do that (use `find' to look for a library).
> >That is about as unreliable as I can imagine -- you have no idea whether
> >that library belongs to the system/arch in question or whether it is the
> >one the user wants. This is just poking in the dark. Besides, it is
> >very very much too expensive searching a whole directory tree for a
> >file!
>
> Hrm, yes I was a little queasy with the approach, but I actually got it
> from something in the AC archives -- ac_python_devel to be exact -- and
> so I figured it wasn't \emph{too} bad. Mea culpa.
No need to excuse yourself. The authors of that macro should feel bad.
I thought python had language facilities to extract this information by
running a script?
> (ac_python devel is at:
> http://autoconf-archive.cryp.to/ac_python_devel.html
> )
In any case, they assume unportable library naming scheme, don't allow
for either caching or giving a default value in order to override the
find part.. Have they ever heard of lib64[1]?
IMHO they should just leave alone PYTHON_CPPFLAGS and PYTHON_LDFLAGS if
the user has pre-set them, and otherwise just try to find headers and
libraries by AC_CHECK_HEADERS/AC_CHECK_LIB.
> >If you must know during configure whether it exists or not, try to link
> >against it using AC_CHECK_LIB. If you must be able to choose whether to
> >link against a shared library only, you can look at Bruno Haible's
> >macros from gettext (look at gnulib's `gettext' or `iconv' module to
> >find them), I'm not sure but believe that may help. Alternatively,
> >Libtool's macros may be of help but may be overkill.
>
> Actually I'm trying to find the appropriate -L<text> option to pass to
> the compiler. Is there a smart way to do this via AC_CHECK_LIB? These
> are paths that I don't expect will be in default compiler (err, linker)
> search directories.
Actually, FWIW I don't like this approach at all. If the package uses
pkgconfig, that would be a semi-clean way of obtaining this information.
Otherwise, let me give you an argument against automated search:
I (a presumed user of your software package) have two versions of the
library installed, in different prefixes. Either two different but
compatible versions, or one development and one optimized version, or
whatever else. I as a user *want* to have the choice which one to use.
All I could imagine as useful would be to have one variable/switch to
prevent the user from having to set both of CPPFLAGS=-I... and
LDFLAGS=--L.. accordingly. I know there exists a macro for this in the
autoconf archive, but have forgotten its name. I would not recommend
doing this either, though: CPPFLAGS and LDFLAGS are pretty standardized,
easy to override for both the casual user _and_ easy to automate for the
packager of your favourite software distribution. The latter is not to
be underestimated.
*snip the rest I agree with*
Regards,
Ralf
[1] yes, I know about the Libtool deficits in this area..
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
