[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SSL bundle
Re: SSL bundle
Mon, 11 Feb 2008 15:15:20 +0100
Mozilla-Thunderbird 126.96.36.199 (X11/20080110)
Fred Kiefer schrieb:
David Ayers wrote:
I think you should consider deprecating the automatic inclusion of
- 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").
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.)
- SSL bundle, Thomas Gamper, 2008/02/08
- Re: SSL bundle, Richard Frith-Macdonald, 2008/02/08
- Re: SSL bundle, Nicola Pero, 2008/02/08
- Re: SSL bundle, Aria Stewart, 2008/02/08
- Re: SSL bundle, David Ayers, 2008/02/10
- Re: SSL bundle, Sašo Kiselkov, 2008/02/10
- Re: SSL bundle, Fred Kiefer, 2008/02/10
- Re: SSL bundle, David Chisnall, 2008/02/10
- Re: SSL bundle,
David Ayers <=