[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 09:09:16 -0700
User-agent: Thunderbird (Windows/20060719)

Thomas Chust wrote:

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.

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. I wonder if I should test both or just require chicken-static. I don't really want to double my build times, nor support chickens that were bootstrapped in different ways. Then again, it would be worth knowing why things come out differently. I guess first off I'll see if I can reproduce your bad results with dynamic builds.

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.

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.

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? My own build environments are fascistly separated from one another. I hadn't thought about bulletproofing against environments that are not quite so clean.

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

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.

Kinda baffling. I'm not supposed to have to specify that an .exe is SHARED or STATIC. Should be a result of the libraries it's linked with. So, the wrong libraries are linked. Hmm.

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 :-(

Well, we haven't ruled out unhealth in your own environment.

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!

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

Brandon Van Every

reply via email to

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