As far as compiling, I really only have much experience with the various forks of Glest, which use cmake, usually with some optional paramaters for the location of config files and data, etc.  Megaglest even has a script for it included in the download.

For pre-compiled, *.deb packages are extremely convenient for users of Debian-based Linuces like Ubuntu and Mint, but that's not something I have experience making.

Honestly? A README and possibly a helper script. A "proper" build system will help by reminding the user when they are missing dependencies, but unless you need the flexibility I say RTFM :).

For distribution a .deb would be cool.

Honestly? A README and possibly a helper script. A "proper" build system will help by reminding the user when they are missing dependencies, but unless you need the flexibility I say RTFM :).

For distribution a .deb would be cool.

Prefered method : a .deb :)

If I had to compile it, then a makefile. And to generate I would recommand cmake because I was a noob at generating makefiles and learnt cmake easily. Peoples in my lab who do crossplatform C++ all use cmake too.

I usually prefer autoconf+automake. But I see no problem using cmake either.

For packages (.deb, .ebuild, .rpm, etc) let the community make them to you, otherwise you will have always to answer complains like: "Why do you support distribution XYZ and not YZK?" "Why do you not support architecture X at your package?", etc.

I wrote two .sh scripts that should first fetch all the FLARE dependencies (untested, I think I got them all!) and second checkout and compile the code from the source in the svn repository (works like a charm!). These scripts will only work if your particular Linux distro supports sudo and apt-get (Ubuntu for instance).

get_FLARE_dependencies.sh: http://ubuntuone.com/p/fpb/

update_and_compile_FLARE.sh: http://ubuntuone.com/p/fpd/

Before running either of these scripts, you have to chmod them to be executable.

Naturally, you only have to get the dependencies once. Every time there's a new revision available, you can run update_and_compile_FLARE.sh to run the latest version available.

pfunked: If you want, I'll make a .sh script like the above to include with your source code download for Ubuntu users.

pennomi: I think that's all the dependencies, or at least what I installed on a clean Ubuntu install in order to build it.

Hi guys,

I've knowledge in the following areas:

- sw development on GNU/Linux

- building stuff from source using make, autotools, cmake

- maintaining build support in a project using GNU Autools and CMake

- Debian packaging (I mean the real thing: debian.org/doc/maint-guide not just randomly putting stuff into an archive and calling it foo.deb)

- cross-compiliing in general, maintaining build recipes in OpenEmbedded

- maintaining the support for CMake in OpenEmbedded

From my perspective flare is best served by using a build system based on CMake because:

- very good support for CMake in all free OSes, Debian/Fedora/XYZ packager can help making the build system better

- clear support for cross-compiling

- CMake uses a modern and intuitive syntax and its online documentation is good

- CMake supports those 'other' operating systems and their proprietary development environments very well (nobody is excluded)

- CMake is used by other important F/OSS game projects (namely Wesnoth) and those can be used to look for best practices

A few words regarding autotools:

- very good build system; serves important need; very stable

- unfortunately *widely* misunderstood and used in appropriate ways

- AFAIK difficult to handle for Windows people

My 2€ cents. People can find a patch adding a CMake-based build system to flare here: code.google.com/p/flare-engine/issues/detail?id=1

Regards,
Robert