gnustep-dev
[Top][All Lists]
Advanced

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

Re: gnustep-make experiment


From: Nicola Pero
Subject: Re: gnustep-make experiment
Date: Mon, 12 Feb 2007 19:01:19 +0100 (CET)

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

I agree with Matt and others that we want to have gnustep-config able to
output compile/link flags.  I have a plan in mind for that. :-)

But in your case, what about some makefile variable/function that lets you
check if a gnustep library is installed or not ?

We could add to gnustep-make a

 GNUSTEP_FIND_LIBRARY

and 

 GNUSTEP_FIND_FRAMEWORK

functions, that would return the location of a GNUstep library/framework, or
nothing if they don't exist.

Then in your GNUmakefile you could just do

ifneq ($(call GNUSTEP_FIND_LIBRARY, Gorm)$(call GNUSTEP_FIND_FRAMEWORK, Gorm),)
 SUBPROJECTS += GormPalette
fi

to compile your GormPallette iff libGorm.so (or Gorm.framework) is installed, 
without even needing the configure step. :-)

Thanks


NB: Here is an example GNUSTEP_FIND_LIBRARY implementation for you to test with 
--

GNUSTEP_FIND_LIBRARY = $(strip $(wildcard $(addsuffix $(strip $(1)).so, \
$(GNUSTEP_SYSTEM_ROOT)/Library/Libraries/lib \
$(GNUSTEP_LOCAL_ROOT)/Library/Libraries/lib \
$(GNUSTEP_NETWORK_ROOT)/Library/Libraries/lib \
$(GNUSTEP_USER_ROOT)/Library/Libraries/lib)))

It would be defined inside gnustep-make though, so it will get automatically
updated for the filesystem changes.  You call it, and gnustep-make will make 
sure
to look in the right library locations.

PS: We could do this with standard variables (rather than functions), but 
functions
have a more familiar syntax, and it looks like all GNU makes in the last 5 
years or so
support them, so we should probably start using them.





reply via email to

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