GSL_CFLAGS, GSL_LIBS, gsl.m4

GSL_CFLAGS, GSL_LIBS, gsl.m4

[William Brower]

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

Re: GSL_CFLAGS, GSL_LIBS, gsl.m4

[Brian Gough]

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

Re: GSL_CFLAGS, GSL_LIBS, gsl.m4

[Christopher R.Gabriel]

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