Re: gnustep-make experiment

[David Ayers]

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.

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.

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.

Cheers,
David