Re: GSL_CFLAGS, GSL_LIBS, gsl.m4

["Christopher R.Gabriel" <cgabriel at mixadlive dot com>]

On Wed, Aug 02, 2000 at 09:25:53PM +0100, Brian Gough wrote:
> Your second problem can be fixed, I think, by using "#include
> <gsl/gsl_foo.h>" (this is now the recommended way to do it, a change
> from earlier versions of gsl).
> 
> Regarding the flags that come out of gsl.m4 and gsl-config, I believe
> they follow GNOME's conventions. I'm not sure exactly how that
> evolved, as I don't follow GNOME myself. I'd be glad of an
> explanation/introduction to this type of package configuration scheme
> from anyone on the list who knows about it.
> 
> William Brower writes:
>  > 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.

Mmm you're right here. The CFLAGS and LIBS (the "generic" ones) are saved in ac_save_LIBS before the script append them GSL_LIBS end _CFLAGS, but won't restore them. 

>  >
>  > 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?

That's because, as Brian noticed, the recommended way to include GSL 
headers is #include <gsl/gsl_bar.h>, so that's why you have 
/usr/local/include instead of /usr/local/include/gsl.

>  >
>  >
>  > 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).

You're right: this is the reason with blasnative is not there.

>  > 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.

I'll check for this.

Christopher