Re: [Chicken-users] understanding the CMake build

[Brandon J. Van Every]

Thomas Chust wrote

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

Why do you have include and library search paths at all?  Chicken knows 
where to find its *.h and library files; it's all compiled into 
chicken-defaults.h.  Caveat: MSVC Chicken built with makefile.vc doesn't 
use chicken-defaults.h and is kinda clueless.  But all the Autoconf and 
CMake builds work identically.  Anyways, do you need chicken.h in your 
non-Scheme source code for some reason?  I may be betraying my lack of 
Chicken development experience here.

Regardless, I believe there are ways I can bulletproof the include and 
library search order better.  I've had to do this at times for other 
reasons, like Autoconf polluting the source tree with its own 
chicken-defaults.h.  If you had stuff lying around in your source tree 
from an old Autoconf build, that could be the culprit.


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

For this kind of issue, you'd need to write a trivial CMakeLists.txt 
that reproduces the problem, then get on the CMake mailing list and 
report the bug.  I'd do it if I had a Mac, but I don't.  Ditto Linux.  
I'm only good for Windows reproducers of whatever flavor.

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

Yes, but it's also clumsy to build underlying third party libraries with 
GNU Autoconf.  People do it all the time, and nobody expects it to be 
seamless.  We can evangelize and try to CMakeify more projects, but the 
reality is, there will always be projects that don't use CMake.  Chicken 
is such a project in fact.  When you type "make dist", CMake runs the 
needed Autoconf commands in autogen.sh.  I'd suggest learning to use 
CMake to drive external build tools.  CMake scripting isn't lovely, but 
it is portable and it integrates with CMake.

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

Not likely.  There will always be new programming languages.


Cheers,
Brandon Van Every