Re: SSL bundle

[David Ayers]

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

Cheers,
David