David Ayers wrote: > Nicola Pero schrieb: > >> 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 >> >> BUNDLE_NAME = MyBundle >> ... >> MyBundle_NEEDS_GUI = NO >> ... >> >> 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 ;-) > > 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.
No problem, make the change in -make and I'll change PM - its a few lines of code anyway... > > Cheers, > David > > > _______________________________________________ > Discuss-gnustep mailing list > Discuss-gnustep@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnustep > _______________________________________________ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep