The Niotso codebase previously functioned through custom makefiles. You cd into the zlib folder and type in ‘make’ to compile zlib. You cd into the libpng folder and type in ‘make’ to compile libpng. And the same with each and every package in the codebase, which you *must* perform in sequential order. Anyway, this really is efficient enough for quick experimentation of new code, but now that my packages have started maturing, I’ve been interested in making the end product more proper and functional out of the box.

CMake is the only portable and convenient alternative to this. And it’s not perfect, since many all-too-common features are just left out because I think the developers just forgot about them. You can’t specify different cflags for different packages, the names by which your compilers are invoked are hardcoded into CMake and unchangeable, there is absolutely no support for shell scripting, and the language is just atrocious without basic features like escape characters or ternary operators. But the main concept behind CMake is what matters: abstract build targets into strings so they can be referred to without having the knowledge of their destination file names. This way, you can say, “Package X depends on the shared version of Package Y”, as opposed to, “$(DIST_FOLDER)/PackageX$(EXE): ${DIST_FOLDER}/PackageY$(SO)”; the latter is not only less intuitive, it also (in regular makefiles) requires manually maintaining a list of all built executables and libraries so you can delete them at user request.

While the GNU autotools aims for portability and can on its own take care of dependency and header tracking (what build system can’t?), it requires both a Bourne-compatible shell preinstalled and a Unix environment set up to provide information about your system like hardware and language. Then the generated project is tied to GCC on all platforms. CMake is the only build system generator for all the popular compilers and IDEs (that I’m concerned with, at least), giving the user choice and more flexibility, and at the larger scale inspiring more (friendly) competition between compiler writers.

But being such an idealist, I don’t believe this is enough. There needs to be a single Universal Codebase Definition format (*.ucd) which all IDEs can agree to. Each source file added to a UCD file may override its inherited type (such as “C Source”), cflags, link flags, etc. and specify output directories, dependency targets (which need not correspond to files), and libraries to link with. Variables describing the system are predefined by the UCD parser, such as platform, endianness, compiler, availability of compiler headers, and so on; custom test scripts may be provided inside the UCD file. In addition to this, UCD files shall be fully modular, letting the user detach any subdirectory of one project’s codebase for use in that of another. Of course, this will require all the toplevel definitions (like cflags and make rules) to be redefined by each file, but seeing as we’re talking kilobytes at most here, the convenience is well worth the increase in size. Under this system, imagine opening up your IDE and being given easy access to drag and drop other UCD projects into your own projects.

One concern of my own that I kept revisiting, numerous times over, in picking the right build system for Niotso, is that my codebase consists of many individual packages strewn together into the same repository for convenience. While the GNOME project has hundreds of unique packages which all are large and different enough to warrant its own owner and repository, I have been setting up my code so (to name an example) just the xa reading code is its own library which is actually bundled together with all the other unrelated file reading libraries that I don’t even maintain myself, like libpng, libmpg123, or libexpat, and interacted with as part of the larger FileHandler interface library. Which is linked to not only the Client, but also the FARDive utility. So far, I still haven’t had the time to extract libpq from the entire PostgreSQL source code (powered by the GNU autotools) because it refers to headers from all over the place. With UCD, the IDE could detect where each and every .h and .c file is, and simply move them over for you. Why hasn’t this happened yet? Why aren’t we funding this?

No technical reason, it’s just it’s not implemented yet. Because CMake at least does the job for my specific use case (and many others’), and is also trusted by large open source projects (including Blender, Compiz, KDE, libpng, LLVM/Clang, MySQL, Ogre3D, and Scribus), I have no pressing need to work on UCD, until far in the future when Niotso hits grand release.

So I’ll clarify, Niotso has completely transitioned over to CMake and can now be compiled with one command. I’m now currently initiating work on libvitaboy, the OpenGL character rendering and animation system for Niotso.