[Top][All Lists]

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

Re: SSL bundle

From: Nicola Pero
Subject: Re: SSL bundle
Date: Fri, 8 Feb 2008 15:53:25 +0000

But the SSL bundle still doesn't build, because it wants to link with gnustep-gui...., I see no reason in that. Additionally I can't find any clue where these dependency comes from.

The 'dependency' (actually there is no real dependency on gui) will be coming from the gnustep-make files. When gnustep-gui is installed it registers itsself in the gnustep-make files so that bundles can be built with it. If gnustep-gui is then manually removed from the system (ie without doing a 'make uninstall' to remove it cleanly) its makefile can be left behind so that gnustep- make tries to link all bundles with it even though it's no longer there.

Try removing $GNUSTEP_MAKEFILES/Additional/gui.make

This seems to happen often enough that it should either be in the FAQ or we should figure out some way for gnustep-make to cope with the situation automatically. We obviously can't depend upon gui being uninstalled cleanly.

Yes, the current behaviour is rather clumsy and mechanical: if gnustep-gui has been installed, it's linked in, if not, it's not. This is applied to all bundles, regardless of whether they actually need gnustep-gui or not.

It would be nice instead for the author of the bundle to be able to control if gnustep-gui should be used when linking or not; ie, if it's a "GUI bundle"
or a "non-GUI bundle". :-)

Maybe a gnustep-make variable to switch from GUI bundles to non-GUI ones ?

Something like

include $(GNUSTEP_MAKEFILES)/common.make


include $(GNUSTEP_MAKEFILES)/bundle.make

that would be recognized (only by new versions of gnustep) to mean that gnustep-gui should not be linked in even
if available/installed.

If the variable is omitted, gnustep-gui would be linked in by default (if available), as it happens now.

Comments on the idea are welcome ;-)


reply via email to

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