mulle-objc 0.14 Release
After a lot of rewriting, testing and valgrinding the time has come to release mulle-objc 0.14 into the wild and to get going on 0.15 :)
Quite a bit of effort has gone into making the mulle-objc repository structure more transparent. The repositories have been reorganized into github organizations and each organization has its own homepage.
This year should see this blog revived, as I will try to push out a weekly article about some aspect of mulle-objc or mulle-sde. There is so much new and interesting stuff in here, that I am sure I won’t run out of topics. Also every Tuesday at 14:00 CEST there is a Twitch Stream dedicated to mulle-objc, where you can see mulle-objc actually being used.
The highlights of the 0.14 release, besides the usual slew of bug fixes, tweaks and minor features are:
The Foundation library will see more changes in 0.15, as is will need to support MulleEOF. This time around the most important change is the way the Foundation is built.
Legacy workflow support
Not so keen on using
cmake ? You can now use the MulleFoundation as a
standalone library to link against. So it’s very easy to use
make or some
other build tool to produce mulle-objc executables.
Runtime and root classes
The initialization steps of MulleObjC known as the “big bang” have been simplified a lot.
- mulle-objc-compat, compatibility layer for Apple Objective-C function calls
- objc-compat, compatibility layer for various Objective-C runtimes (currently Apple only)
If your Objective-C code relies on a common subset of objc runtime functions
class_lookupMethod, you can now add
mulle-objc-compat to your dependencies and do not have to write
objc-compat is a small abstraction layer, to unify code that uses various Objective-C runtimes. It’s mostly concerned with message passing. I use this to port my own libraries to mulle-objc, that need to keep running under other runtimes as well.
If you have seen the Twitch stream, you will know already, that it is now possible to have multiple Objective-C class systems in the same app/process. This is a useful for writing plugins for third party apps for example.
Also there have been constant refinements on the function naming scheme, to make function names more expressive.
All mulle-sde tools now
.mulle folder for storage. This reverses
the proliferation of little
.mulle-<toolname> folders. It also makes it
easy to remove mulle-sde from a project and startup a-new.
The build process of the dependencies can be now much quicker, if mulle-craft is able to parallelize the build. All mulle-core projects are able to be built in parallel. There are more parallelization opportunities ahead, so this will become even faster in the future.
mulle-test is now based on mulle-sde, and mulle-sde is cognizant of
mulle-sde. This simplifies testing to
mulle-sde test. Tests have also
been parallelized. It’s faster than ever.
mulle-env has seen a fairly complete overhaul, with respect to tool handling. It
mulle-sourcetree has also see a big revision. The buildorder is now inheriting and overriding marks in a more predictable way.
mulle-core-developer is a nice starting place to develop cross-platform C projects with mulle-sde.
mulle-clang and mulle-lldb improvements
The debugger mulle-lldb has been adapted to the changes in the runtime. The compiler supports now multiple universes. Quite a few of the compiler macros and flags have changed. Check the README.md for details.
For more details checkout the releasenotes in each project.