This is the mail archive of the
gsl-discuss@sources.redhat.com
mailing list for the GSL project.
Re: configure enable/disable gsltest
- To: Bill Brower <wbrower at ll dot mit dot edu>
- Subject: Re: configure enable/disable gsltest
- From: Brian Gough <bjg at network-theory dot co dot uk>
- Date: Mon, 10 Jul 2000 23:05:10 +0100 (BST)
- Cc: "gsl-discuss at sourceware dot cygnus dot com" <gsl-discuss at sourceware dot cygnus dot com>
- References: <3969243A.5B9D7198@ll.mit.edu>
- Reply-To: gsl-discuss at sourceware dot cygnus dot com
The disable-test option only turns off the compilation part of the
test. It still looks for gsl-config. I'm not sure why it works that
way, but that's what the option does anyway (it probably needs better
name).
To get make use of the results, try something like
AM_PATH_GSL(0.6.0,[have_gsl=true],[have_gsl=false])
AM_CONDITIONAL(HAVE_GSL, test x$have_gsl = xtrue)
and in your Makefile.am
if HAVE_GSL
PROGS = app1 app2
else
PROGS = app2
endif
bin_PROGRAMS = $(PROGS)
That is based on the example in the conditionals chapter in the
automake manual.
Bill Brower writes:
> another configure/gsl.m4 issue?
>
> configure --disable-gsltest
>
> and
>
> configure --enable-gsltest=no
>
> seem to have the same, incorrect result.
> Both go ahead and check for gsl-config and the library.
> Am I correct in assuming these flags are supposed to
> prevent the GSL checks from taking place?
>
> Now a related question. Let's say I have an autoconf'ed
> project called "top" which builds a two applications
> "app1" and "app2". Say "app1" requires the GSL
> but "app2" does not. Is there a graceful way to NOT
> attempt the build of "app1" if someone configures
> with "--disable-gsltest"? How about if the gsltest
> check fails? I've read the autoconf/automake
> manuals but examples seem to be worth much more.
>
> Cheers,
> Bill
> --
> William Brower MIT Lincoln Laboratory
> 805.355.1310 KMR Field Site, Kwajalein
>