GSL_CFLAGS, GSL_LIBS, gsl.m4

[William Brower <wbrower at kmrmail dot kmr dot ll dot mit dot edu>]

In gsl.m4, it appears that instead of just
making GSL_LIBS and GSL_CFLAGS, there is the
attempt to append these results to the more
general CFLAGS and LIBS variables.

Is this what you want to do? My package builds
multiple libraries and multiple binaries. Some
of these require the GSL, some do not. When the
more global CFLAGS and LIBS variables are messed
with, my non-GSL apps have all that extra baggage.

Also, my GSL_CFLAGS gets set to '-g -O2 -I/usr/local/include'
but the headers are in '/usr/local/include/gsl' so
my Makefile.am's have to look like '$(GSL_CFLAGS)/gsl'
Should the flags used to build the GSL be inherited
by *my* package? Should there also be defined a GSL_INCS
that shows only the (correct) path to the headers?

One more. My GSL_LIBS gets set to '-L/usr/local/lib -lgsl -lm'
Forget about the fact that -lgslblasnative is not present
(I suspect that is to allow someone to link against their
own BLAS lib but that's not my concern right now).
I notice that when X_LIBS (or somthing) is set, it usually
only contains the *path* to the library (the -L part),
not the libraries themselves. I supppose one could argue
that in light of there being only ONE library (-lgsl),
it is OK to add it (and its -lm dependency).
It appears inconsistent; then again, I don't have enough
experience to know the "right" way to do this.

--
William Brower  MIT Lincoln Laboratory
805.355.1310    KMR Field Site, Kwajalein