Re: [Chicken-users] understanding the CMake build

[Thomas Chust]

On Sun, 10 Sep 2006, Brandon J. Van Every wrote:

> [...] Hrm.  Well, it's true that I canonically build with the Chicken 
> 2.3 MSVC binary chicken-static.exe.  I've done no testing of building 
> from chicken.exe at all.

Hello,

apparently some autotools weirdness broke the build without installed 
chicken-static, because a fresh rebuild with the CMake generated 
dynamically linked chicken compiler executable works flawlessly. You still 
get only dynamically linked executables out of the build, but more on that 
further down in the message...

> [...] This should be fixed in Darcs HEAD.  Don't use the .429 tarball 
> for CMake builds.  Actually we need to release a .430 tarball if things 
> hold up to scrutiny.

I did use the current darcs head -- the last darcs pull command was issued 
in my shell around 2006-09-10 15:00 UTC.

> >  [...]
> >  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.

> 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 ;-)

> >  [...]
> >  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++
> >  libraries!
>
> 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. I'm happy that CMake has 
halfway decent SWIG support -- but the Java support is terrible at the 
moment.

And by the way, it's not at all impossible to create a JNI wrapper around 
the CHICKEN library and to use that from Java. It might even be useful if 
you wanted Java solely for its portable GUI functionality.

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

cu,
Thomas