Re: [swarm-hackers] Permission to add a Makefile to trunk...

[Bill Northcott]

On 20/11/2009, at 1:11 PM, Scott Christley wrote:
> A makefile for OSX is fine.  There is no need for any OS-independent stuff 
> though, just put the makefile in the macosx subdirectory and assume you are 
> on OSX.

Swarm uses autoconf and friends which generate configure scripts and makefiles. 
 
These two lines in your makefile:
        cd swarm && ./autogen.sh
        cd swarm && ./configure --enable-openstep --without-jdkdir
configure and build the makefiles for current host.

The body is buried in the contents of autogen.sh, and the various configure.in 
(or configure.ac) and Makefile.am files.
> 
> I tend to think that the frameworks should be installed under 
> /Library/Frameworks so all users have access but that's just a preference.  
> In reality, we want to build a binary distribution for easy installation.  I 
> think we probably want to use the Mac Installer application to handle the 
> install as there are a few things to be installed in a variety of places.

I would second those suggestions.  The Mac installer allows for system tests as 
well as before and after scripts, which can be used to set up environment 
initialisation files etc.

> For these packages, the abovementioned makefiles will serve no purpose, these 
> makefiles are only an attempt to make life for the average user of swarm as 
> easy as possible.

As Scot says, building Swarm libraries is unlikely to get even slightly simple 
anytime soon.  I think it is better to focus on ease of use for a modeller who 
starts with a binary, which one of us has built.  On MacOS X that means 
templates for Xcode and possibly Eclipse, and trying to make sure that model 
code which runs on Linux or Windows also runs on MacOS X without changes.

You are taking on a huge task to attempt to maintain builds for a number of 
platforms. Better to concentrate on one, and get others to ensure that nothing 
else got broken.

> ...These makefiles will be for users who want the latest from subversion, the 
> packages will be stable-but-slightly-out-of-date.

Anyone trying to build from the latest SVN sources really needs to know where 
they are at.  As Scott says it is complex. I think documentation of the 
existing build machinery would be vastly more useful than yet another build 
mechanism.

Cheers
Bill