[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gnustep-make experiment

From: Richard Frith-Macdonald
Subject: Re: gnustep-make experiment
Date: Mon, 12 Feb 2007 12:24:14 +0000

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:
macros to be included in scripts via GNUSTEP_MAKEFILES?
3) invoke 'make' with gnustep makefiles in some config subdirectory
during ./configure
4) other ideas which I may have missed?


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]