The upcoming mulle-objc 0.22.1 release (II): Almagamation

Amalgamated library mulle-core

I wanted to reduce the compile time, but keep the project structure as is. As it is now, there are many reusable libraries with a topic (e.g. mulle-fifo) but the cost of calling cmake on each of them add significantly to the compile time.

The clib project provides the infra-structure to embed sources from other C projects into your own C project. The new library mulle-core uses this to “amalgamate” all mulle-c, mulle-concurrent, mulle-core projects, that do not need special linker treatment. To enable mulle-sprintf to be part of the amagamation library, I had to let go off the MULLE_C_CONSTRUCTOR way to piece the various parts together.

Gone are the package.json files, which conflict with clib which used package.json as a synonym for clib.json.

The net result is, that the compile speed on Linux is now back to the speed before the Linux compile speed kernel regression, which I am not sure will get fixed ever.

One downside of a amalgamated library is, that the same source is now part of two projects. If there was a bug in say mulle-fifo, it’s not so easy to get to the proper issue tracker. A fictious pull request, could also not be handled.

Amalgamated library MulleFoundationBase

You can do the same for the Objective-C library, up to the point, where it diverges into OS specifica (namely MulleObjCOSFoundation, with its subprojects). The way MulleObjCOSFoundation is structured as subprojects and not as individual projects, becomes more and more of a burden. But all projects “beneath” it can be combined into a new library. Again build time reduction is the benefit.