macOS ships with libc++abi, which doesn't provide the hooks required
for interop, so this was causing all of the tests to fail to link in
the Travis macOS test. We're now correctly detecting that it won't
work on macOS and disabling those tests.
Some applications still include the old objc-class.h header expecting
to obtain the declarations contained in objc/message.h and
objc/runtime.h nowadays. This commit adds this header to achieve
out-of-the-box compatibility with these applications.
On FreeBSD and OSX, the block runtime functions are defined on a Block.h
and a Block_private.h headers on the include path as opposed to
libobjc2's objc/blocks_runtime.h and objc/blocks_private.h respectively.
This commit amends libobjc2's install routine to create the
FreeBSD-style headers as symlinks to the ones provided by libobjc2 for
improved compatibility.
Some applications still include the old objc-runtime.h header expecting
to obtain the declarations contained in objc/message.h and
objc/runtime.h nowadays. This commit adds this header to achieve
out-of-the-box compatibility with these applications.
Apparently, setting -lpthread is not enough to convince gcc to actually
link a thread library, so if we are using pthreads, set the -pthread
flag as well. It fixes the gcc situation and doesn't have any adverse
effects for clang either.
systems after some further testing.
Currently, we have three build systems for libobjc2:
- GNUmakefile, which provides a number of options but not very cleanly (i.e.
the only way of knowing what they are is to read the source) and doesn't
correctly build the Objective-C++ runtime.
- Makefile, which works correctly for a single configuration, but requires
tweaking by hand to build others.
- Makefile.clang, which is experimental, doesn't really work, and confuses
people.
The new CMake system:
- Correctly installs in a GNUstep location if one exists, or in a system
location otherwise. This is configurable at build time.
- Provides inspectable options for all of the configuration choices (run ccmake
to see them all)
- Easily supports cross-compilation and out-of-tree builds
- Is easy to extend and inspect
- Automatically builds the LLVM optimisations (which already use CMake, as it's
the only clean way of building LLVM optimisations out of tree) and can be
easily configured not to if they are not required.
- Will build a single libobjc.so for platforms that provide a separate C++
runtime and a separate libobjcxx for ones that don't.
- Can generate build files for make, ninja, XCode, Eclipse, and Visual Studio
For those unfamiliar with CMake, the best way of building is an out-of-tree
build. For the simplest case, it's just a matter of:
$ mkdir build
$ cd build
$ cmake ..
$ make
$ sudo -E make install
If you wish to edit any of the configuration options, the easiest way is to run
ccmake instead of cmake. You can also run ccmake . from the build directory to
edit the options after initial configuration.
For faster builds , try using ninja instead of make. Add -G Ninja to the
[c]cmake command line and then run ninja instead of make.
David Chisnall
David Chisnall
David Chisnall
Daniel Ferreira
davidchisnall
Daniel Ferreira
Niels Grewe
theraven
ericwa
thebeing