chicken-users
[Top][All Lists]
Advanced

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

Re: [Chicken-users] understanding the CMake build


From: Thomas Chust
Subject: Re: [Chicken-users] understanding the CMake build
Date: Sun, 10 Sep 2006 15:31:51 +0000 (GMT)

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




reply via email to

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