[swarm-hackers] preparing for debian packaging

[Scott Christley]

Hey Swarm developers,

I've been working to get Swarm into Debian as a package (and consequently in 
Ubuntu as well).  I have most of the packaging files working for compiling the 
ObjC core of Swarm with tcl/tk/blt.  It installs great and I'm able to compile 
and run heatbugs.  However there are a few issues that I'm trying to decide how 
best to handle.


Issue #1) Right now Swarm can be configured and compiled in three different 
ways.

* non-GUI Swarm
* tcl/tk/blt Swarm
* GNUstep Swarm

I've been playing around with the configuration and Makefiles to figure out how 
I could compile and generate all three possibilities.  It looks to be a real 
pain.  The issue is that some files would have to be compiled three times (once 
for each configuration).  Multiple compilations of a single file with different 
configurations doesn't seem to be something that the GNU autotools handles very 
well (if at all).  I can think of two possibilities.

A) Leave the source code the same.  Create three separate Debian packages which 
produce three separate libraries.  However this would require renaming of the 
libraries files and maybe the header directory; this is so that all three 
Debian packages could be installed at the same time without conflict.

B) It would really be nice if the non-GUI Swarm truly acted like a core 
library, then the GUI libraries were added "on top" of that core.  I'm not sure 
if this is possible because the core ends up being very different for GNUstep 
versus tcl/tk/blt.  For example, Swarm classes are subclassed from NSObject for 
GNUstep and Object for tcl/tk/blt.  We could have two swarm "cores" though.


Issue #2) Compilation of GNUstep Swarm doesn't really work anymore.

We tried modifying the Swarm makefiles so that they include in the proper 
GNUstep headers and libraries.  The problem is that all of the environment 
variables that we used to use are no longer defined for GNUstep.  GNUstep has 
changed their setup so only a single environment variable is required, then its 
own internal scripts and makefile system handles all of the underlying 
complexity.  Trying to "duplicate" the GNUstep makefile system within the Swarm 
makefiles is essentially a hack.  We really should use the GNUstep makefile 
system to compile Swarm for GNUstep.  Supporting two separate sets of makefiles 
looks to be really difficult, I tried doing some mix-mash of the GNU autotools 
and GNUstep makefiles but it doesn't really work very well.

A) I don't really have a good solution.  One radical possibility is to end-line 
tcl/tk/blt support, keep it going with bug fixes and such in a final release 
branch, then let the main Swarm development branch go completely GNUstep.

B) I suppose there might be some way using to GNU autotools to have it include 
in different makefile sets, essentially constructing GNUstep makefiles or GNU 
autotool makefiles depending upon the configuration.


Issue #3) Despite the objc runtime abstraction work, it seems Swarm local 
libobjc is still needed.  I tried disabling it but it seems there is mframe 
stuff required.  This won't fly for Debian packaging because those libobjc 
header files are installed in a way that conflict with the system libobjc 
header files

A) Maybe it is a simple solution of moving the mframe files directly into the 
Swarm src and out of the local libobjc?

B) If tcl/tk/blt will always be dependent local libobjc then change/move the 
libobjc header directory so it doesn't conflict with the system libobjc.  Note 
that this isn't an issue for GNUstep because GNUstep doesn't need mframe.



*******

If I had my choice in the matter I would:

1) Get rid of the local libobjc.
2) End-line tcl/tk/blt support.  Make the necessary changes so that it could be 
installed as a separate Debian package for posterity.
3) Make main development of Swarm be purely GNUstep based.

While having Swarm support multiple GUIs is grand idea, the amount of work 
required seems exorbitant compared to the gain and it isn't clear that it can 
be done anyways with the fundamental difference in the "core" between GNUstep 
and tcl/tk/blt.

What do you think?

Scott