Mac OS X binaries of SVN version (Page 1 of 9)

jammnrose, you've added "the needed files to compile on osx with Xcode", but this takes 26 Mo, i.e. as much as the full game isn't it too much ?

Even if size is not a problem on the track repository, it will be bothering to download all these files for non-Macos users.
For example, each time I have to package the Windows version, my script will download all your files, and will have to remove them for the final package.

Alternatively, if said files are not likely to change at all, perhaps offering them via a seperate download link would be most efficient. (If one really does need to download 26MB)

Ugh.  Yeah.  Get those binary dependancies out of the repo.  What's the plan there?  Updating a binary file in the repo every time one of the dependancies makes a release?  That's not what version control is for.  It's a waste of space.  Dependancies must be acquired separately by anyone choosing to build the source.

And a 4MB zip of GIMP source?  GIMP source in the repo is great, but zipped it's useless.

As for the 28MB .app bundle, that's kosher.  It's normal to include binary deps with the application.  It may lead to wasted space for the user (having multiple .apps with the same deps) but that's just How It's Done on the Mac.

Seeing there's currently no one around that could sort this out, I've removed the directory for the time being.  Why not provide it as separate download instead?

I was under the impression that luc's universal binaries include all the necessary files but, since it's been in the repository already, you or anyone else can also retrieve it with

$ svn checkout https://s.snth.net/svn/neverball/trunk/macosx@884

There's nothing wrong with providing binary dependencies per se.  It's a bad idea to keep them in the repository, because then you're misusing the repository merely for storage, when in fact its purpose is version control.

Last edited by parasti (2007-05-03 10:54:24)

From rlk's comment, there's a couple of things that should be addressed:

  * binary dependencies -- these don't belong in the repository;
  * archived GIMP source files -- should not be archived, okay otherwise.

These have nothing to do with large file size, and so should be treated separately.

There are two main bottlenecks with regards to file size:  icons and project files.  I don't have a Mac, so I'm not quite sure what the "dmg_back" images are for, but is there any way you could reuse the icons in dist?  Also, I find it hard to believe that project files can take up so much space.  Dev-C++ and the now-removed MSVC project files take up less than half a megabyte each, Xcode project files take up 5.2 megabytes!  Make sure only project files are provided.  Any files that can be generated at compile time should be removed.

Some of the images can be removed as only one is actually for the dmg background.
This icon is a background that is used when the dmg is opened. It's like setting an image to be a folder's background in windows. Many dmg's do this.
I will look at making sure that only the needed files are included. I see a few candidates for removal.

Personally I would have never figured out how to compile without the project files. Also, if we don't have these files we are making Mac users figure it out themselves.
Dev-C++ is a very good compilier/IDE for windows but I think xCode is even more so for Mac.

Edit: also remember that being in svn effectively DOUBLES the size (at least, I'm fairly sure of this).

Last edited by jammnrose (2007-05-06 18:51:23)

Yeah, I can say the same for myself, although, as you did, I obtained the project from Luc.
So I can see the sense in offering it, esp. in an open source context such as this.

Then I guess the only issue is making it a reasonable size. I still feel if there's no way of making it manageable, that's kind of a deal breaker, and we can still make the project available through the forums, as it is currently.
I don't believe the background image is necessary, the user can decorate their dmg however they want.

I believe you are correct parasti.
The build directory can be empty.