mulle-objc 0.21 Release

How to update

To update an existing mulle-objc project, you should clean the (global) archive cache and throw away the old downloaded dependencies in stash. Then upgrade the project and rebuild:

mulle-sde -f clean cache
mulle-sde -f clean tidy
mulle-sde upgrade
mulle-sde craft

This should give you no trouble.

What’s new ?

There are some new features and improvements, including a technological world premiere and … some breakage.

Colorization for terminal output

In logging statements color output can be very helpful to quickly scan output lines for the same object. There is a new method -colorizedUTF8String which will be used by the printf extension format “%#@” to print a colorized description of the object.

Implementing a colorization for an object can look like this:

- (int) colorizerColorCode
{
   return( 111); // 256 color terminal code
}

- (char *) colorizerPrefixUTF8String
{
   char   *s;
   int    color;

   color = [self colorizerColorCode]
   mulle_asprintf( &s, "\033[38;5;%dm", color);
   return( MulleObjCAutoreleaseAllocation( s, NULL));
}

-colorizerPrefixUTF8String and -colorizerSuffixUTF8String will be called by -[NSObject colorizedUTF8String].

mulle_asprintf will create a malloced terminal color string, which will be returned autoreleased.

C callbacks for NSThread

NSThread is very convenient to start a new thread. Yet until now, to just let a small function run, you needed a class and a method. Now you can just pass in a C function and some user info.

+ (void) mulleDetachNewThreadWithFunction:(MulleThreadFunction_t *) f
                                 argument:(void *) argument;

+ (instancetype) mulleInitWithFunction:(MulleThreadFunction_t *) f
                              argument:(void *) argument;

Support for static Objective-C executables (Linux)

With musl libc instead of glibc as the standard C library it becomes possible to create Objective-C executables that do not need any shared libraries. mulle-markdown is an example of such a standalone executable.

As far as I know, a fully statically linked Objective-C executable has never been done before, so I claim this as “World Premiere Tech” 😉

Support for Jetbrains / CLion

You can now conveniently set up a basic mulle-sde CLion project with

mulle-sde extension add idea

Setup the default toolchain, to use “mulle-clang” as your C compiler and “mulle-gdb” as your debugger and you should be ready to develop mulle-objc projects in CLion.

Improved Windows support

Some time as been expended to make mulle-objc work on Windows (WIN32). The tooling should be OK and the libraries up to MulleObjC should work. There hasn’t been enough effort yet to achieve proper Windows support in MulleObjCLockFoundation and MulleObjCOSFoundation.

You use WSL to build native versions of the mulle-objc libraries, and you can then use the native mulle-clang-cl.exe in Visual Studio as the Objective-C compiler.

mulle-sde config switch

I am writing a graphics library, that I want to base on multiple backends. This library called MulleUI has a dependency named MulleUIOS, which can be based on either libsdl or glfw. With config select i can now choose between two different sets of dependencies. MulleUIOS has two sourcetrees alternatives. “config is the default and “sdl” is the alternative. MulleUIOS usually selects glfw, and the projects headers and cmake files are “reflected” for it.

With mulle-sde config switch you can now choose in “MulleUI” the sourcetree that “MulleUIOS” should use. This is done via an environment setting in the main project. This will force on the next craft a new “reflect” in “MulleUIOS”, which changes the C headers and cmake files in “MulleUIOS”. So for example the source code in “MulleUIOS” changes from #include <libsdl.h> to #include <GLFW.h> or vice versa.

Foundation brew formula is broken (MacOS)

Unfortunately the ‘homebrew’ formula for Foundation.rb is broken. It seems to me, that the brew project really goes out of its way to make things as cumbersome as possible for formula writers. You can still build the Foundation with mulle-sde with no problems though, but it’s just not possible to use mulle-sde within a brew formula to fetch something via curl…

Raspberry PI llvm build is broken

The llvm code base does not compile with the old gcc compiler delivered with bullseye and the clang of bullseye crashes when compiling lib/Target/AArch64/AArch64ISelLowering.cpp.

Release Notes

This is the list of release notes of the various projects. Enjoy the read :)

MulleFoundation

The most interesting change is the addition of MulleObjCTimeFoundation, which was spawned by MulleObjCOSFoundation and MulleObjCValueFoundation as a home for NSDate and NSTimer. Overall not a lot has changed here.

MulleWeb

There is a new project mulle-markdown. It’s a small executable to convert markdown to HTML. It’s a showcase for the use of musl with mulle-objc, to produce a self-contained executable with no shared libraries linked.

Otherwise there have been no real changes to MulleWeb.

mulle-objc

Finally the synced version numbers are a thing of the past. It’s expected that mulle-objc-runtime and MulleObjC remain syned, but the others will likely fall behind (and have fallen behind).

New is the addition of mulle-musl-gcc for support of the musl C library.

mulle-cc

mulle-gdb remains essentially unchanged, but follows the gdb version. The mulle-clang compiler received an update to the newest llvm version and a code generation bug was fixed.

mulle-core

mulle-fprintf and mulle-sprintf have seen some significant changes.

mulle-time now distinguishes between “calendar” time and a process’ “absolute” time.

mulle-concurrent

There is nothing new for mulle-concurrent.

mulle-c

mulle-c11 is now supporting Windows better. There is now support for the musl C library (Linux/FreeBSD only).

mulle-sde

mulle-sde sees a major new feature, with the addition of multiple sourcetrees per project. This makes large projects like the MulleFoundation more easily configurable.

mulle-nat

mulle-project now contains the convenient mulle-gitignore script!