On Jun 16, 2004, at 10:39 PM, Hans-Christoph Steiner wrote:
Here's what I think needs to be done:
- pick one system to provide necessary libs for all (I think Fink works best for this)
- the package needs to be compilable from lines in a Makefile (This makes complete automation possible)
- the code should be in the Pd CVS (This also makes automation much easier. It looks like
PDP/PIDIP/GEM2PDP are already there, I don't know where GridFlow is and ideally Gem could be moved back to the Pd CVS since it only really works with Pd anyway)
Is this list for the requirements for the package maintainers or for end users of the package?
For GEM the suggestions break down like this:
Fink - I have never used Fink at any stage of building GEM - it's not necessary.
Makefiles - Anyone is welcome to construct a makefile build system, but the binaries are more than adequate in my view. The projectbuilder project is often out of date, but only three people use it regularly and, to the best of my knowledge, only two others have ever built it (or even inquired about building it) on OSX.
CVS - What would be the reason for moving it? We have a nice little setup as it is and if someone wants to contribute then they just need to contact Johannes.
I would suggest that the people involved in this project focus on producing a very stable and well tested binary release rather than worry about fancy automated builds and continually tracking down the proper libs. To that end I would make the following list:
- Only use libs included with the stock version of the target OS or statically link all non-standard libs. This will help ensure the widest compatibility among potential users. One of the strong points about developing for the Mac is the consistency among software and hardware configurations, so it's best to take advantage of that.
- The end product should be a double click and run binary like just about every other OSX app in existence. There should be no tinkering around in /usr/ or editing of config files required.
- The version issued to the public should be as stable as possible. This means no random builds out of CVS, but rather highly tested point release builds that have had a reasonable degree of feedback and reports from end users.
Ok that's my take.
cgc