By a release I mean, I tagged the git repository with some version number (0.8), so you still need to download the sources from git if you want to test it. I wont spend my free time to create a website nor distro packages very soon, because I think that for while is better to spend my time coding than creating cosmetic things for a tool not production ready yet.
Ah, I almost forgot to say, meique is a pet project of mine, result of my will to have a more than reasonable building tool for C and C++, a really good one. I’m doing it on my free time and hope to finish it some day, hehe.
Ok, back to the main subject, it’s not production ready… by production ready I mean, if you want to use meique in a near future the best thing to do is to try to port your project to meique and report any bugs and wishes, so bugs can be fixed and wishes turned into reality.
So, what meique can do until now?
Out of source builds.
Find installed packages using pkg-config as backend.
Support projects with multiple source directories.
Decide if a file need to be recompiled by their contents, not by their timestamp.
Multiple jobs at once.
Detect the file dependencies and also use this information the decide if a file needs to be recompiled.
Automatic creation of the following targets: all and clean (install and uninstall not done yet).
Scopes for OS, compiler and build types, like the ones used in qmake.
What it can't do yet?
Probably there are some (maybe many?) bugs, because I did only few tests and I'm still to lazy to convert my manual tests into automatic tests.
There's no equivalent helper function to cmake configure_file function.
There's no windows port yet, to create it is a matter of create an os_windows.cpp which implements the OS interface, i.e. few
functions inside a namespace (rm, mkdir, cd, pwd, etc).</li>
There's no install function yet, I need to think a good API for it to support Mac OSX frameworks, simple UNIX installs and the mess found in Windows systems, so I wont implement anything until I have a clear and simple API for it in my mind.
Support for tests, something like the add_test function of cmake.
Documentation! Currently the only documentation is the source code itself, mainly meiquescript.cpp and the meique.lua files used to compile meique itself.
How to get it and report bugs/wishes?
You can get the sources on gitorious (http://gitorious.org/meique). Compilation can be done using cmake or meique itself.
To report bugs and wishes write to hugo.pl at gmail.com.
I’m talking about my pet project called meique, yes, this is yet another build tool.
The project is going a “bit” slow, I can summarize this situation in numbers, the project had 15 commits so far, 4 in 08/2009, 4 in 12/2009 and 7 in 04/2010. In other words, 4 commits, 4 months doing nothing, 4 commits, 4 months doing nothing, 7 commits, …
As you can see there is a pattern in meique development, every commit represents 1 month doing nothing! But this isn’t my fault, ok.. is my fault, anyway I want to break this pattern, no… no… I’m going to break this pattern!! at least I hope so.
Besides all development slow down I achieved some goals with those 15 commits:
The basic architecture to provide the basic functionality is done, or almost done :-).
Meique can now compile basic hello worlds \o/.
So what's missing and what's next?
Missing? A lot of things. My current implementation plan is:
Implement the source directory structure replication, used to the separated build dir compilation feature.
Create a very basic preprocessor, just to identify the dependencies of a C++ file on each run.
Use md5 or a faster hash algorithm to identify when a file needs to be recompiled.
Support multiple jobs, -jN option.
Redo this list with four more items.
For anyone interested on meique, take a look at gitrotious project page.
I admit myself, I have a bit of the “Not written by me” syndrome, but I guess that this time this is not a side effect of this developer disease, it’s just because every build tool in this planet sux in a way or another, so I decided to write my own build tool, yes… the build tool of my dreams!
Before start to talk about it, I like to answer why not X? why not Y? Ok, let’s do it one by one.
Why not Autotools?
If you really like Autotools, sorry, this post isn’t for you. Bye!
Why not qMake?
qMake is useful only for Qt-based projects, and IMHO, for the simple ones. Ok, Qt is a huge project and uses qMake, but did you ever found someone spreading good words about qMake? In other words, I never use qMake for my Qt projects, I use cmake instead.
Why not SCons?
SCons is somehow a good build tool, last time I used it was two years ago, I like the SCons bootstrap methodology but I dislike the python dependence, summarizing, IMHO CMake is better.
Why not CMake?
CMake is the best build tool nowadays, simple use cases remains simple and complex use cases are possible. I use it for all my projects, so I know that it’s not perfect yet.
CMake syntax is horrible and too verbose.
CMake uses a declarative approach to describe the build process, despite of the declarative nature of the action of describe a project, many times when writing a custom target with CMake you think yourself "If I could use an imperative language, my life would be easier".
CMake is big! 12MB is big!!
You need cmake installed to compile a CMake project.
Why not X?
I don’t know X, so X is too new or probably not so good :-), but if X is really good, just assume that what I’m doing is a side effect of the “Not written by me” syndrome.
Why not Meique?
Yes! Meique is perfect! Is the build tool of my dreams! the holy grail!! but it does not exists yet, the current source code still not useful, I’ll push something to gitorious when it be able to compile the first Hello World.
Ok, so let’s talk about my vapor ware, first the desired features.
Out of source builds.
Self-contained, small, no dependencies besides C++ standard library.
Flexible, extensible and intuitive, uses Lua as scripting language, an imperative language!!
You can bootstrap it! So you don't need it installed on your system to compile a project based on Meique.
Integrated testing support (like ctest).
Meique isn’t a meta-buildsystem like CMake, i.e. it doesn’t generate files for native building tools like Makefiles, Visual Studio projects, etc. Meique itself call the compiler, take care of what should and what shouldn’t be compiled, etc. This adds a bit more complexity to the project, but open the road for useful features like:
Decides if a file needs to be compiled by their contents change, not just timestamp.
A single behavior on all platforms.
Update the file dependence list on-the-fly.
I don't need to write a lot of back-ends for a lot of systems that I never used.
The Meique Lua API is almost done, I just need to think easier ways to write the equivalent of CMake FindPackages, a simple Hello World could be described as:
The stupid example above shows nothing, because build tools intent to be used mainly by medium/big and sometime complex projects, so I’m trying to create a good API based on my experience with CMake, qMake and SCons and why not, my personal hate against Autotools.
P.S.: If you search about Meique, probably you will find an old website at luaforge, this was my first attempt to create a build tool, the source code reflects my understanding of building tools 5 years ago, so forget about it.
