Re: gnustep-make experiment

[Richard Frith-Macdonald]

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.