I would recommend using cmake over scons or auto tools.
The problem with auto tools is that it isn't cross platform unless you want to generate makefiles for each compiler you come across. And doesn't generate project solutions for KDevelop, Visual Studio or XCode. CMake syntax is alot easier and actually readable.
Problems I've seen but correct me if I'm wrong is that you need to learn another language to use it. Python in this case. Its clean. But it doesn't create project files for ide's either.
CMake is cross platform. It generates project files for every ide you can think of and even just makefiles if you prefer. It uses a clean scripting and uses the files CMakeList.txt. Alot easier to use. Though it takes a little time but not much to make them for the libraries you need, though it includes liek over 40 libraries+. And you can request some from CMake's bug site.
The output is very clean, and like scons clean too. But it comes with a complete count while compiling so you know how long until its finished compiling. I'll post it for cmake when I get my system development stuff setup on my machine.
Getting into Linux/Cross Platform Development
I do multi-platform development (building the same software natively on multiple platforms). I do cross-platform development (building software for multiple platforms hosted on a single platform). There is nothing like the autotools for accomplishing those tasks. Nothing.
The new so-called "replacement" tools like scons or cmake are simply inadequate. They require that the tool be installed by the target user, the do not support cross-platform builds, and if you want to build for a new platfom, you must first port your tool before you can port yor software.
Yes, there is a learning curve for the autotools, as with any advanced tool that accomplishes a complex task. Yes, there's some archaic syntax and sometimes byzantine rules about what must needs be applied when. There are some interesting replacement projects underway that will, when (or if) competed provide the same featureset as the autotools, but so far there are no candidates for replacement.
I would like to point out that setting up a typical autotools project take one command (autoscan followed by editing two files (configure.ac and Makefile.am). I manually create no files and the editing consists of replacing boilerplate.
My recommendation is that you buckle down and learn to how to use the autotools. It's not that difficult, it's actually quite well documented (the red book, the info pages, the manual that comes with the software in PDF form). There are loads and loads and loads of examples available to follow.
The new so-called "replacement" tools like scons or cmake are simply inadequate. They require that the tool be installed by the target user, the do not support cross-platform builds, and if you want to build for a new platfom, you must first port your tool before you can port yor software.
Yes, there is a learning curve for the autotools, as with any advanced tool that accomplishes a complex task. Yes, there's some archaic syntax and sometimes byzantine rules about what must needs be applied when. There are some interesting replacement projects underway that will, when (or if) competed provide the same featureset as the autotools, but so far there are no candidates for replacement.
I would like to point out that setting up a typical autotools project take one command (autoscan followed by editing two files (configure.ac and Makefile.am). I manually create no files and the editing consists of replacing boilerplate.
My recommendation is that you buckle down and learn to how to use the autotools. It's not that difficult, it's actually quite well documented (the red book, the info pages, the manual that comes with the software in PDF form). There are loads and loads and loads of examples available to follow.
Quote:Original post by BregmaEver tried running autotools on a system without Make installed? Windows, for instance (sans cygwin)?
The new so-called "replacement" tools like scons or cmake are simply inadequate. They require that the tool be installed by the target user
Quote:the do not support cross-platform buildsI am sitting here on a Mac, with a mingw and linux cross compiler, and a CMake project that builds all 3 targets simultaneously. Why you could certainly do that with autotools, it wouldn't be any easier.
Quote:and if you want to build for a new platfom, you must first port your tool before you can port yor software.Tell that to anyone who spent months porting an autotools-based build system to Mac or Windows. From my experience, autotools is only decently portable between very vanilla *nix environments.
Quote:Original post by swiftcoderQuote:Original post by BregmaEver tried running autotools on a system without Make installed? Windows, for instance (sans cygwin)?
The new so-called "replacement" tools like scons or cmake are simply inadequate. They require that the tool be installed by the target user
It's true. You need a shell and a compiler, too. An runtime libraries. And headers. What you don't need is any of the autotools installed.
Quote:Quote:and if you want to build for a new platfom, you must first port your tool before you can port yor software.Tell that to anyone who spent months porting an autotools-based build system to Mac or Windows. From my experience, autotools is only decently portable between very vanilla *nix environments.
I have ported software written using autotools to both Mac OS X and Windows. It goes pretty much like this.
./configure makeI didn't bother converting the project to use a different build system.
Mind you, I was using MingW32 on Windows. The autotools does require a POSIX build environment. It's extremely portable between anything vaguely POSIXlike or Unixlike (ie. it ran fine on my Atari ST and Amiga).
Biggest advantage to using the autotools is that there's an awful lot of software out there that already suses it, so (a) if you run into problems it's already been solved by someone else, and (2) you will probably end up having to understand it in order to use third-party software anyway.
Have you ever considered using Java for your projects? I find C++ incredibly burdensome for hobbyist game programmers and always cry a little when I see it used when it's not really needed. There are some really good opensource IDEs for Java such as Eclipse available for any *nix, 3D engines such as JMonkeyEngine and so on. And it's cross-platform of course. :)
I'm just trying to say that there are easier alternatives to this horrible autotools/library/C++ mess.
I'm just trying to say that there are easier alternatives to this horrible autotools/library/C++ mess.
I am using autotools myself, and give it a thumbs-up. Here's a tutorial:
Autotut
really? I count only 2 or 3 --configure.ac and Makefile.am and maybe a header to include in config.h-- everything else is generated with (in linux) 'autoreconf -vifs'
Autotut
Quote:Original post by essial
To get a fully working "compile", you have to have around 5 files you have to manually create
really? I count only 2 or 3 --configure.ac and Makefile.am and maybe a header to include in config.h-- everything else is generated with (in linux) 'autoreconf -vifs'
Quote:Original post by Bregma
I do multi-platform development (building the same software natively on multiple platforms). I do cross-platform development (building software for multiple platforms hosted on a single platform). There is nothing like the autotools for accomplishing those tasks. Nothing.
Not true, the KDE project moved from autotools to CMake sucessfully, and it compiles on *NIX, Windows, and Mac OS X, without problems (other than non-portable code problems, X11 dependencies, etc).
Quote:Original post by HuntsManQuote:Original post by Bregma
I do multi-platform development (building the same software natively on multiple platforms). I do cross-platform development (building software for multiple platforms hosted on a single platform). There is nothing like the autotools for accomplishing those tasks. Nothing.
Not true, the KDE project moved from autotools to CMake sucessfully, and it compiles on *NIX, Windows, and Mac OS X, without problems (other than non-portable code problems, X11 dependencies, etc).
Correction: KDE compiles natively on various Posix (where CMake has been ported) and WIN32 platforms without problems. It does not build at all on platforms where CMakes has not been explicitly ported already. It does not cross-compile at all. You will not see KDE running on your ARM-based handheld any time soon, because it just takes too long (weeks) to build under an emulator, and first you have to bootstrap the entire OS and port CMake. I'd like to see THAT done on a gameboy.
KDE chose to use CMake because they don't need to port to new compilers or operating systems. Fair enough, You can also limit yourself to those platforms. After all, they all run on consoles and handhelds, right?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
