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.
Post a comment
All comments are held for moderation; basic HTML formatting accepted.