On 12 Feb 2007, at 11:51, David Ayers wrote:
Richard Frith-Macdonald schrieb:
On 11 Feb 2007, at 11:23, David Ayers wrote:
Should we
1) tweak the environment to allow AC_CHECK_LIB to work?
2) create our own:
- AC_CHECK_GNUSTEP_LIBRARY
- AC_CHECK_GNUSTEP_FRAMWORK
- AC_CHECK_GNUSTEP_NATIVELIBRARY
macros to be included in configure.ac scripts via GNUSTEP_MAKEFILES?
3) invoke 'make' with gnustep makefiles in some config subdirectory
during ./configure
4) other ideas which I may have missed?
[snip]
Of your list of ideas ... I think
1 is obviously good,
2 i can understand having our own checks for frameworks and bundles,
but I don't understand the library/nativelibrary distinction ...
wouldn't you just use AC_CHECK_LIB?
3. OI don't really understand this one.
Well the reason for the native library stems from the essentially
obvious fact that native libraries are libraries on non-Darwin systems
and frameworks on Darwin system (well unless your name is Matt and
you've implemented native frameworks in GNU/Linux and GNU/Hurd ;-) ).
So when /checking/ for projects that are native library projects we
could duplicate -make's logic to decide to use _LIBRARY or
_FRAMEWORK in
every configure.ac script, or we could add the code to a macro
supplied
by -make that could be used by all and that would be updated in sync
with -make when/if other platforms support frameworks.
I see. That makes sense.
I guess the ideal would be to use AC_CHECK_NATIVE_LIB everywhere, and
let that macro determine whether we are dealing with a library or a
framework and set the flags accordingly? That sounds live a very
useful facility to have.
But I actually want to clarify what I meant with the third option for
the configure issue... My goal is to have ./configure of GDL2
identify
whether libGorm is installed/usable so it can decide whether the
palette
should be build or not.
(The servers I deploy my GSWeb App on do not have X/AppKit/GORM but
use
GDL2 & GSWeb... currently I need to disable building the palette
explicitly via configure option.)
Now most configure checks like AC_CHECK_LIB work by trying to build a
minimal example code snipit and link it against the library. For
GNUstep we probably need a lot of the features of -make to
accomplish this.
So to avoid duplicating -make in new configure macros, one could
imagine
creating config/gorm/ subdirs which contain a minimal test.m file
and a
minimal GNUmakefile (or have them generated by the new macros). And
then
have ./configure invoke 'make' in this subdirectory to see if this
minimal project can be built/linked to decide whether to set a
./configure variable or not.
Right ... that's clear now, thanks.
It sounds like a very reliable approach ... and is consistent with
the way autoconf/configure tends to work (ie by actually checking
that something works rather than simply querying a database of
information).
OT1H, I feel this might be "shooting at pigeons with canons" (is that
expression used in English?), yet OTOH it might be the only reasonable
approach without duplicating -make features in configure macros
especially for the cross-compilation case.
I'm not familiar with the phrase, but I suspect it's equivalent to
'using a sledgehammer to crack a nut'
I agree ... that it sounds like doing a lot of work to get a little
information, but gnustep-make is fast, so i don't think it would be
much slower than what autoconf macros already do in similar cases.
Unless someone comes up with a better idea, I like yours.
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev