Build tools such as Automake, CMake, or SCons, try to shield the unfortunate C or C++ programmer from crafting compiler and linker commandlines for myriads of different compilers and compiler versions. Each of these tools has a slightly different focus - some prefer cross-platform features, and some focus on fully supporting all of the Unices. Each is unbeatable in doing its job. Basically, all you have to tell them is, for example, "Compile these files as C, and make a library out of them!", and they do what you want.
Automake, CMake, and SCons do not, however, help you in managing your project. All of us know that, once the project has grown beyond a certain size, restructuring it can become a nightmare. Even moving one header file can break the build for a day or two, since everybody has to adjust include paths. Or, even worse, consider you split a library into two or three separate libraries because it has acquired too many responsibilities over time - you'd have to instruct everyone who has used the library about the new structure. (People often argue that a project's structure does not contribute any quality measure, and that the time spent on the structure be better spent on getting the code right. This is certainly a valid view of the matter, but it's a different story, and I don't argue against. Anyway, if you do not care about structure, then you should only be reading on if you want to use the features of Automake but don't want to learn its damn syntax.)
Project structure maintenance is of course but one of Confix's features, although the strongest. The following list is a rough compilation of things that Confix can do for the programmer.
Automake is one of the most widely used build tools in the Unix
Open Source community. Everybody who likes hanging around there
knows the configure && make && make
install dance, the hallmark of Automake. But, as comfortable
as it is for the end user who is in charge of compiling and
installing a package, as odd it is for the maintainer of the
package. Confix tries to take away the complexity from the build
instructions, and defines it own minimal set of functions which are
mapped onto the Automake language. (Actually, Confix project files
are written in Python, so chances are you don't have to learn yet
another language).
Maintenance of the include path that has to be set when compiling source code is one of the great challenges in build administration. You have to take care that you point the compiler in every directory that contains header files needed for the compilation. This is often accomplished in a trial and error kind of way. More than that, one often faces the issue of leftover directories in the include path - ones that did contain needed header files way in the past, but which are either not needed for the compilation anymore, or which have been moved. As a consequence, include paths tend to grow rather than shrink. Note that this include path problem is one of the reasons why project structures tend to become a maze - the cost of moving files around rises with the size of the project.
Confix knows which compilation needs which header files (by simply parsing the files that are subject to compilation), and can match this information against the location where these headers are. This way, at the heart of its implementation, it maintains a graph which contains enough information to be able to compose a correct include path for every compilation - without requiring the programmer to do anything.
Placing the libraries you need on the linker command line is a task which is at least as tedious as composing a correct include path. In addition to determining all the libraries that you need, you have to take care to place them on the linker command line in the correct order (most linkers are very particular about open references pointing in the wrong direction). Needless to say that one would rather refrain from changing the library structure when he expects linker lines breaking and people getting annoyed.
Confix solves this problem similar to the include path problem described above. As it knows who needs what, it is not difficult to compose a correct linker line - again without demanding anything from the programmer (except to keep reference cycles out of the project, but this is a matter of hygiene anyway).
For various reasons - project size, organizational, or simply
taste (to foster good interfaces, for example) - it might make sense
to split a big project into several smaller ones that are
independently maintained. With Automake, the granularity of a
project is the unit with which one does the configure
&& make && make install dance. A project is
finally made public by saying make install, and this is
how project teams communicate changes: one team installs a
tested version of their project (or releases it for installation),
and the other team uses it.
With Confix, you split a project by moving files, and nothing else (well almost).
A lot of Confix's energy goes into fighting the overhead of project structure maintenance (you guessed it - I'm a fan). Here's a short summary of the other - minor - things it can do.
<subdir/file.h>,
without putting it into a directory subdir.Confix is licensed under the GNU Lesser General Public License.
You can download releases from the project summary page on Sourceforge. The most recent stable release is 2.1. If no release is recent enough, you may always checkout a development version from Subversion. You can also browse the Subversion repository without having a Subversion client installed.
Follow the instructions in the INSTALL file.
Umm, well. There is a bunch of it, but it has been extremely outdated since the 2.0 release. It is a good reading if you want to grasp how Confix intends to solve the problems it is there to solve, but it does not explain the way Confix is currently trying to solve these problems. (You can view the manual here as HTML and Postscript, if you want.)
For the time being - until the documentation is up to date
(probably never) - please refer to the Examples section
below. confix2.py --help gives a great deal of
information as well.
Fortunately the number of projects that use Confix is not infinite,
so it is possible to list them in a concise way. As a documentation
substitute, you may have a view into their project layout and their
various Confix2.pkg and Confix2.dir files -
and their source code of course, but that's a different story.
A C++ unit test framework, modeled after the way I use the Python unittest module in the Confix test suites. I wrote it out of frustration with the existing unittest frameworks out there. As such, I left off all the bloat: no GUI with colorful progress bars, no dependencies on any other package in the world. It not even depends on the Boost library which would have come in quite handy, but which has a horrible build system. All one needs is a reasonably standards conformant compiler (which shouldn't be hard to get your hands on these days). For fun and educational purposes, the framework "bootstraps" itself in three stages, testing every aspect of itself before that aspect is used in the next stage.
The most fancy output one can get looks like this (taken from stage three of its own test suite, just before its completion).
+ jf::unittest::tests::Stage2Suite
+ jf::unittest::tests::SetupTeardownSuite
- jf::unittest::tests::SetupTeardownSuccess...ok
- jf::unittest::tests::SetupTeardownSetupFailure...failed
- jf::unittest::tests::SetupTeardownSetupError...failed
- jf::unittest::tests::SetupTeardownRunFailure...ok
- jf::unittest::tests::SetupTeardownRunError...ok
- jf::unittest::tests::SetupTeardownTeardownFailure...ok
- jf::unittest::tests::SetupTeardownTeardownError...ok
+ jf::unittest::tests::StartStopSuite
- jf::unittest::TestStartStop...ok
- jf::unittest::SuiteStartStop...ok
------------------------
#Success: 7
#Failures: 2
#Errors: 0
#Tests: 9
#Suites: 3
------------------------
Details follow ...
------------------------
Failure: jf::unittest::tests::SetupTeardownSetupFailure: result.num_error() == 1 (/home/jfasch/work/confix/unittest/trunk/basics/tests/setup_teardown.cc:89)
Failure: jf::unittest::tests::SetupTeardownSetupError: result.num_error() == 1 (/home/jfasch/work/confix/unittest/trunk/basics/tests/setup_teardown.cc:117)
A cross platform (well, Windows/Unix) toolkit with associated applications. The base package nicely abstracts away networking, threading, and a few more aspects of both operating systems. The messenger application uses the Fox cross platform GUI toolkit.
The HACKING file gives an overview of what you're getting involved with. As opposed to the documentation, the implementation documentation reflects a current state. It is automatically extracted from the source using the extremely cool Epydoc.
There are three Confix mailing lists on Sourceforge.
Most of all I'd like to thank the handful of people that are using Confix, and who continue to provide valuable input. Most of these people are good ex-colleagues of mine.
I also express my thanks to my former employer, Salomon Automation, who made it possible to go open source with Confix. I have spent a considerable amount of working hours on it, and appreciate that it is not selfunderstood for a company to take that step. At least, it pays in a way that I am still maintaining the project after leaving the company.