[Top][All Lists]

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

Re: SSL bundle

From: David Ayers
Subject: Re: SSL bundle
Date: Mon, 11 Feb 2008 15:15:20 +0100
User-agent: Mozilla-Thunderbird (X11/20080110)

Fred Kiefer schrieb:
David Ayers wrote:
I think you should consider deprecating the automatic inclusion of
gui.make by:

- moving the current gui.make from Additional to Auxiliary
- having a new gui.make in Additional use the technique above to insure
backward compatibility for at least the next release
- yet emit a warning that automatic inclusion is deprecated.

I think projects like ProjectCenter and ProjectManager should be able to
include the correct -make file fragments based on their project type.

That may be fine for server applications but all project out there that
rely on gui.make being included automatically will fail in the future
and for now would result in a deprecation message. What I could see as
an exceptable solution is to have Nicolas explicit flag to not include
gui.make or introduce new make templates like non-gui-application and
not include gui.make there.

I'm not sure what you mean by 'new make templates'. Currently even the most minimal GNUmakefile will include gui.make simply becuase -make will included it because it's there...

Maybe you mean new templates that simply define that define?

Or maybe you mean that $(GNUSTEP_MAKEFILES)/ tool.make, ctool.make, bundle.make, clibrary.make, framework.make, gswapp.make, gswbundle.make, java.make, java-tool.make, jni.make, native-library.make, objc.make, service.make test-library.make test-tool.make should all define the flag? But how would it be undefined if the user actually /does/ want to link against -gui.

Maybe it would be easier if application.make, palette.make and test-application.make simply included Auxiliary/gui.make (if it gets moved).

Of course this would expect that bundle.make, library.make and framework.make builds that currently rely on automatic inclusion of -gui to include it explicitly. Would that be enough to alleviate your worries?

In most cases it does not cause any trouble to always include gui.make.

I guess that depends on the definition of 'most cases'.

Only on already inconsistent systems we should be able to produce a
better warning message and fall back to something sensible.

Interestingly I don't find this reason too important... should we really add maintenance burden for broken installations? I guess it depends whether it's simple and straight forward. But this is not the reason I see for suggesting the change. It merely triggered the suggestion (quasi "aus gegebenen Anlass").

The ability
to link without gui is a nice add-on, that should be possible, but not
on the cost of breaking most applications out there.

Ok, we can just disagree here and since you're currently maintaining -gui single handedly, I don't want to make your life any harder if your expecting trouble here.

I'd be fine with a variable to stop the linking of -gui but we could probably also to the same for -base for objc.make projects? (These are seldom but use them once in while for testing and linking against -base does set many objc runtime hooks.)

(note that for objc.make projects -base/-gui are actually not linked because FND_LIBS and GUI_LIBS aren't linked. Yet the rest of the defines like -fconstant-string-class=NSConstantString are set.)


reply via email to

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