Dear András,
I updated my Mac to Lion and as a consequence tried to improve the Mac support
a bit.
I have pushed two more commits to raimar/cmake:
* gcc 4.2 is now detected and the targets for the four script that would not
compile with this version are removed. Xcode 4 still ships with gcc 4.2, this
doesn't seem to change any time soon.
* I added install targets for the scripts and the libraries to the cmake
framework. Under Linux it is the responsibility of the user to install to
default locations or otherwise configure the dynamic linker so that the
libraries are found (i.e. /etc/ld.so.conf.d, LD_LIBRARY_PATH) and to call
ldconfig after installation. Under Mac the situation is more delicate. The
library paths are hard coded to the binaries and dependent libraries, these
paths are changed to the install prefix once everything is installed. This way
scripts can be run without installing as before (including the possibility to
move them around as long as the build dir exists) exactly as it always has
been. Additionally it is now also possible to install everything and then the
binaries no longer depend on the build directory. The install targets are
still undocumented yet, but most users would expect them to exist anyways out
of habit.
Also, I updated the documentation in raimar/Documentation. I completely
rewrote the Mac OS section to make it better suited for users with Mac OS 10.7
or newer: it is now possible to avoid the installation of the complete Xcode
suite and install only the command line tools. This is only 136.37 MB instead
of the 4.4 GB Xcode 3 download. Xcode 4 is not as large as Xcode 3 (1.8 GB)
because Apple decided to factor out some lesser used libraries and tools.
Unfortunately the command line tools are not available for 10.6 so there Xcode
3 is still needed.
I found the installation of dependencies to be much faster and easier with the
"Homebrew" package manager. It provides everything one needs for the C++QED
compilation (including blitz mercurial version, but not FLENS) and installs
much less dependencies compared to MacPorts because it makes better use of
what is already present on the Mac OS system. The updated documentation is
written with Homebrew in mind but states that it is also possible to satisfy
the dependencies with MacPorts if this is already installed (which is now true
because blitz has been updated to 0.10 in MacPorts).
I strongly suggest to drop Boost.Build support under Mac OS for now. It turns
out that it only used to work because of a "bug" in Boost.Build, and as we
have seen it was only possible to run the scripts from the root directory of
the framework. Now this "bug" has been "fixed" and not even this works anymore.
I suppose one would have to install everything in order to be able to run it,
but I didn't test as Cmake works just fine. Telling from the bug reports
dynamic linking on Mac OS really seems to be a mess and a constant source of
confusion.
As I was working on the documentation branch anyway I included your
technicalDefinitions.sty to make the branch self-contained. I had to use some
workaround though documented in the commit message.
Finally I updated the getLibs.sh (it is in the branch raimar) to fix some
problems. Instead of editing the Jamroot with sed (which did not work anymore)
the script now gives hints how to call cmake or how to configure boost.build if
the user chooses to install locally. The same tips concerning Boost.Build are
also in the documentation now (edit user-config.jam or site-config.jam to
provide library pathes). I removed Jamroot.hpc and Jamroot.macosx, because on
teaser one can use the user-config.jam provided there or use cmake and on Mac
Boost.Build is broken anyway.
That's all for now, best regards
Raimar
|
