[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] understanding the CMake build

From: Brandon J. Van Every
Subject: Re: [Chicken-users] understanding the CMake build
Date: Sun, 10 Sep 2006 13:00:23 -0700
User-agent: Thunderbird (Windows/20060719)

Thomas Chust wrote

2) CMake builds chicken-static and csi-static -- but they are both linked
    against the *dynamic* libraries belonging to the already installed
    CHICKEN used for bootstrapping. Therefore they don't work at all if
    called after removing the old bootstrapping compiler.

That's bizarre. CMakeLists.txt certainly specifies the correct libraries to link against. Could an old *.h file be picked up from somewhere, with old paths? Do you have a personalized build environment with a lot of Chicken INCLUDE directives in it or something? [...]

Before the second run of CMake and make I made sure that any traces of the old CHICKEN were purged from my hard disk. Also both my include and library search paths are really standard and contain but a single CHICKEN version in them, which is the one freshly installed by CMake now but was the autotools built CHICKEN 2.429 before I started the first CMake build today.

Why do you have include and library search paths at all? Chicken knows where to find its *.h and library files; it's all compiled into chicken-defaults.h. Caveat: MSVC Chicken built with doesn't use chicken-defaults.h and is kinda clueless. But all the Autoconf and CMake builds work identically. Anyways, do you need chicken.h in your non-Scheme source code for some reason? I may be betraying my lack of Chicken development experience here.

Regardless, I believe there are ways I can bulletproof the include and library search order better. I've had to do this at times for other reasons, like Autoconf polluting the source tree with its own chicken-defaults.h. If you had stuff lying around in your source tree from an old Autoconf build, that could be the culprit.

If it is not your environment, then I would suspect a CMake bug. Is this on MacOS X?

Everything I was describing in the last e-mail and this one concerns MacOS X.

Apart from CMake bugs or broken build environments there is another possible reason for the linkage behaviour: As far as I recall, the MacOS X linker is kind of reluctant to link anything statically if there is a remotely similarly named shared library anywhere on the harddisk -- somehow the Apple guys think that static linkage is a deprecated thing and has to be prevented by all means ;-)

For this kind of issue, you'd need to write a trivial CMakeLists.txt that reproduces the problem, then get on the CMake mailing list and report the bug. I'd do it if I had a Mac, but I don't. Ditto Linux. I'm only good for Windows reproducers of whatever flavor.

 In my opinion support for Java and other scripting languages is very
important in case you want to generate wrappers together with your C/C++

So where's the Java support in Chicken. ;-) It's not a Java-oriented project. Bigloo Scheme is, and Kawa Scheme totally is.

That's not the point I was trying to make. CMake is a tool of greater general relevance than only for CHICKEN. And many software libraries are providing wrappers in order to use them from different scripting languages. Therefore support for building such wrappers is a good thing to have in CMake -- maybe not for the CHICKEN build, but for quite a number of other possible uses. It's just clumsy if I want to build my library core with CMake, the language glue code with let's say SWIG and custom Makefiles and the Java interface with ant.

Yes, but it's also clumsy to build underlying third party libraries with GNU Autoconf. People do it all the time, and nobody expects it to be seamless. We can evangelize and try to CMakeify more projects, but the reality is, there will always be projects that don't use CMake. Chicken is such a project in fact. When you type "make dist", CMake runs the needed Autoconf commands in I'd suggest learning to use CMake to drive external build tools. CMake scripting isn't lovely, but it is portable and it integrates with CMake.

Hopefully one day there will be a grand unified build system that works and produces less head scratching than the existing ones ;-)

Not likely.  There will always be new programming languages.

Brandon Van Every

reply via email to

[Prev in Thread] Current Thread [Next in Thread]