Re: [Chicken-users] understanding the CMake build

[Thomas Chust]

On Sat, 9 Sep 2006, Brandon J. Van Every wrote:

> [...] As I don't have a Mac, and I don't really know the quality of 
> CMake's MacOS X support, it wouldn't surprise me if there are troubles 
> here.  Felix, don't you have a Mac?  Not trying to add to your burdens, 
> but we do need someone around here who can test on the Mac at least 
> occasionally.

Hello,

rather sooner than later I wanted to switch from autotools to CMake 
for my CHICKEN darcs head build anyway and since the last few changes in 
the autotools build system seem to have finally broken compatibility with 
the ancient version 1.6.3 of autotools shipped with MacOS X, I was more 
motivated to get CMake working all right.

I figured out now that the problems so far must have been caused by the 
fact that I had never installed a statically linked version of CHICKEN 
from my autotools builds. I now did a clean install of the 2.429 CHICKEN 
tarball in the default configuration, and magically the linker errors 
about undefined symbols during the CMake build disappeared. I have 
actually no clue why this helped, as there should theoretically be no 
difference in the outputs from chicken and chicken-static, but it did 
help.

After the build through CMake completed cleanly, some strange behaviour 
remained, though:

1) The installation script does not complete cleanly beacause it doesn't
    find a file called ChangeLog in the build directory -- this is probably
    trivial to fix, and it's trivial to avoid by touching the file.

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.

3) After installing the fresh CHICKEN, rerunning CMake on the darcs source
    tree, manually setting the EXTANT_CHICKEN cache entry to chicken
    instead of the broken chicken-static and running make once more on the
    build tree, chicken-static and csi-static are regenerated and now work,
    but they are still dynamically linked.

> >     - Windows XP Professional using MinGW gcc-3.2 and MSYS
> >     - Windows XP Professional using MinGW gcc-3.2 without MSYS
>
> Chicken isn't building on these 2 platforms??  This shocks me.  Granted I use 
> Windows 2000, but I build on MinGW / MSYS all the time.  It's my canonical 
> build platform.  Please report any errors on MinGW / MSYS forthwith.  If 
> these aren't building out of the box then something is gravely wrong.  I hope 
> you're just having troubles with VTK here and not Chicken.

I did have some problems with CHICKEN as well, but that's already a few 
weeks from now and the build system has changed again. Maybe I just 
managed to grab one of the unstable states from darcs... I'll test that 
again, when I have access to my Windows machine. Don't panic before I 
complain again together with an error log if the problems haven't 
disappeared ;-)

> >     - Windows XP Professional using Open Watcom 1.5
>
> The support for Watcom in CMake is very recent, and I haven't tested with it. 
> If it is important to you, and you're willing to test regularly the way John 
> Cowan is testing on Cygwin, then I'll set up Watcom and deal with problems as 
> you report them.

Open Watcom support is not that important for me.

> >  [...] Everytime at least the linker flags are terribly messed up in
> >  some creative ways I could never devise when writing a Makefile by
> >  hand ;-)
>
> Are you speaking of VTK here?  Chicken just doesn't have that many linker 
> flags, so I have trouble imagining how they could become tremendously 
> perverted.

Yes, that was a problem with VTK, especially the Java wrappings -- and 
after I tried it out, I also read in some documentation file, that 
building them on Windows is not considered stable, yet. Unfortunately the 
Java wrappers were exactly the thing I needed...

Still, it's strange if *some* build targets added with ADD_LIBRARY(... 
MODULE ...) from a CMake macro do *not* include either the -Wl,--dll or 
-shared flags in their linkage commands, for example.

And it's simply sad, that VTK, which is produced by the same company as 
CMake doesn't manage to get built flawlessly using CMake :-(

> >  [...] I'm especially amazed how CMake manages to screw up Java
> >  compiler and archiver flags as the JDK tools are really easy to use
> >  and have the same command line options on every platform.
>
> CMake is a C/C++ oriented build tool.  Java support is pretty recent and I 
> wouldn't expect much from CMake at all.  I think it's good that CMake wants 
> to expand its horizons to other languages, but the reality is Java is well 
> served by Ant. [...]

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!

Anyway, CMake at least tries to incorporate such useful features and maybe 
it just takes time until they stabilize..

cu,
Thomas