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
_______________________________________________
Chicken-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/chicken-users
