CMake

The discussion about helping Joerg with OWB (more specifically, porting GStreamer) brought up CMake. Has anyone tried porting CMake? CMake is supposed to make building cross-platform apps easier, and I've heard good things about it.

Hans

@Hans
I tryed with no luck (but i do not remember what was problems, and i also not so good programmer). But yes, i think in last days that will be cool if someone will port at last CMAKE. It used pretty offten in today (in many games, and for example even in new version of PUAE it used, and because of it, it hardly builds on os4 for now).

@Hans

I tried a quick port but gave up because CMake needed a working fork(). That said, with more attention, maybe it's possible to work it around. In some cases it's easy, sometimes much less.

@Fab

Quote:

I hope that it won't be too hard to work around the fork() dependency.

Hans

@Fab

Is vfork() enough? Because then I have some code, you might be able to use

@alfkil

I had replaced fork() with vfork() in hope it would work, but it didn't exactly help. :)

So, i think a cmake port will really need some special attention. Since i only needed it for OWB and that OWB compiles much faster on a crosscompilation machine anyway, i didn't bother.

@Hans
Quote:
It depends on how fork() is being used. If it is being used as a quasi-threading mechanism (e.g. GNU make, distcc, OpenSSH) you'll be in for a lot of work. If it is being used to simply execute commands then it is fairly easy to work around it and wrappers like vfork() or the real IDOS->System() will do nicely.

@Hans

has anyone looked at SCons :

http://www.scons.org/

Quote:

SCons is an Open Source software construction tool?that is, a next-generation build tool. Think of SCons as an improved, cross-platform substitute for the classic Make utility with integrated functionality similar to autoconf/automake and compiler caches such as ccache. In short, SCons is an easier, more reliable and faster way to build software.

What makes SCons better?

* Configuration files are Python scripts--use the power of a real programming language to solve build problems.
* Reliable, automatic dependency analysis built-in for C, C++ and Fortran--no more "make depend" or "make clean" to get all of the dependencies. Dependency analysis is easily extensible through user-defined dependency Scanners for other languages or file types.
* Built-in support for C, C++, D, Java, Fortran, Yacc, Lex, Qt and SWIG, and building TeX and LaTeX documents. Easily extensible through user-defined Builders for other languages or file types.
* Building from central repositories of source code and/or pre-built targets.
* Built-in support for fetching source files from SCCS, RCS, CVS, BitKeeper and Perforce.
* Built-in support for Microsoft Visual Studio .NET and past Visual Studio versions, including generation of .dsp, .dsw, .sln and .vcproj files.
* Reliable detection of build changes using MD5 signatures; optional, configurable support for traditional timestamps.
* Improved support for parallel builds--like make -j but keeps N jobs running simultaneously regardless of directory hierarchy.
* Integrated Autoconf-like support for finding #include files, libraries, functions and typedefs.
* Global view of all dependencies--no more multiple build passes or reordering targets to build everything.
* Ability to share built files in a cache to speed up multiple builds--like ccache but for any type of target file, not just C/C++ compilation.
* Designed from the ground up for cross-platform builds, and known to work on Linux, other POSIX systems (including AIX, *BSD systems, HP/UX, IRIX and Solaris), Windows NT, Mac OS X, and OS/2.

@angelheart

I hadn't heard of SCons. It sounds like it's very similar to CMake. I wonder which one (CMake or SCons) is "better."

Having SCons won't help people working on CMake projects, though.

Hans

I found that Scons are used in some games, but, it used not so offten as Cmake. Cmake start to be more and more popular.

@Hans
It seems a new build system that is "better" is created every couple of months. You'll notice there is a trend towards creating yet more configuration management tools as well lately (cvs, svn, git, bzr, etc.).

Let's just say this is not an easy problem to fix in general and there are many different tools available. As to which is the best, it depends.

I lean towards simpler tools myself but unfortunately, some believe their whiz bang tool of the month is the best and you end up having to port the entire build system before you can begin working on the project. This is where cross-compilers are likely the quickest solution to the problem (e.g. Timberwolf).

@ssolie

Quote:

That's all too common a problem unfortunately, as well as having to port a gazillion libraries before even thinking about compiling the main code. It's guaranteed every port will require at least one library you've never heard of and/or hasn't been ported before (or if it has, the person who ported it for their own use hasn't released it - I'm guilty of this too)

CMake - yes, we could do with this, I've seen it rather a lot lately.

I've seen it quipped that some build systems are more elaborate than the projects they are building

@ssolie

Yeah, I know that new tools pop up almost every day. CMake appears to have reached a point where it's significant enough to be work porting. Plus, I'm looking for a tool that eliminates the need to maintain separate makefiles for each platform manually. Something that's relatively easy to use, unlike autoconf/automake.

Hans

@Hans

How about qmake

Actually, I'd like to see cmake, qmake and git (and/or mercurial) being ported to AmigaOS4. Then we'd be up to date with modern developement platforms again.

We need just a few people with too much time

regards,
nexus

@nexus

There's Git on AmiNet (but it doesn't work on AOS4.x).