Re: [bugs #10816] Can't build palettes on win32

[Nicola Pero]

> > > > In win32, you likely have to add a xxx_LIBRARIES_DEPEND_UPON += somelib
> > > > the the makefile.
> > >
> > > can't make be easily made to do this automatically?
> >
> > Um, no - unless you want make to figure out all the external symbols in 
> > your program and go search through your entire hard drive to figure out 
> > which libraries implement them :-)
>
> Yes, but you could make it make a simple assumption that any library linked 
> to also should be made a LIBRARIES_DEPEND_UPON, which, unless I'm missing 
> something, seems logical.

Ahm - yes / no / not sure what the thread means at this point, there seem 
to be some confusion here.

Reading the bug report (and not having a Windows machine to check), to me 
it looks like Gregory's assesment that -lGorm is missing on Windows might 
be the correct diagnosis.

This could either be automated, by adding ADDITIONAL_GUI_LIBS += -lGorm in 
palette.make (probably conditional to GUI_LIB == gnu), or palettes could 
be required to add ADDITIONAL_GUI_LIBS += -lGorm in the makefile if they 
are building a Gorm palette.

Assuming this is what we need, probably automating is a good idea, so here 
is the patch --

Index: palette.make
===================================================================
RCS file: /cvsroot/gnustep/gnustep/core/make/Instance/palette.make,v
retrieving revision 1.26
diff -u -r1.26 palette.make
--- palette.make        12 Jul 2004 03:24:33 -0000      1.26
+++ palette.make        28 Oct 2004 23:16:29 -0000
@@ -71,6 +71,10 @@
    $(GUI_LIBS) $(ADDITIONAL_TOOL_LIBS) $(AUXILIARY_TOOL_LIBS) \
    $(FND_LIBS) $(ADDITIONAL_OBJC_LIBS) $(AUXILIARY_OBJC_LIBS) $(OBJC_LIBS) \
    $(SYSTEM_LIBS) $(TARGET_SYSTEM_LIBS)
+# If this is a Gorm palette, plug in the Gorm library.
+ifeq ($(GUI_LIB), gnu)
+  PALETTE_LIBS += -lGorm
+endif
 endif

 ALL_PALETTE_LIBS =                                             \


If it works (someone with Windows needs to test it), let's put it in. 
Having quickly looked at them, Gorm's own palettes GNUmakefile code might 
need modification if we make this change: in order to find -lGorm on 
windows, you probably need -L../../GormLib/$(GNUSTEP_OBJ_DIR) in there (I 
mean in Gorm/Palettes/0Menus/GNUmakefile.preamble and similar locations), 
we might as well always add it.  From the bug report I deduce you can't 
really build palettes on Windows anyway at the moment (else if you can 
already build the Gorm ones the bug is something different) ?

Other / custom palettes won't need this because libGorm will be already 
installed and so easily found.

If adding -lGorm when GUI_LIB == gnu is too simplistic and the zoology is 
more complex, we should probably not change palette.make then, and require 
palettes' implementors to add -lGorm in the GNUmakefile when they know 
they are building a Gorm palette instead (are non-Gorm palettes possible? 
I suppose you could have an Apple IB palette, probably you could try to 
have a palette where the same source code compiles with both Gorm and 
Apple IB, but it looks like conditionals on GUI_LIB == gnu are enough to 
support this).  If so, it will only be used in Windows (and systems were 
linking is compulsory) even if you add it to ADDITIONAL_GUI_LIBS 
regardless of machine type, so implementors might well just always add the 
IB library they want to use to ADDITIONAL_GUI_LIBS, and that should work.

Thanks