Re: [Chicken-users] understanding the CMake build

[Brandon J. Van Every]

Thomas Chust wrote:
> On Sun, 10 Sep 2006, Brandon J. Van Every wrote:
>
> > [...] 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.
>
> Because there is no way *not* to have at least the default search 
> paths of the C compiler enabled, unless one uses a customized GCC 
> buid. And because there is also no way *not* to have at least the 
> default search paths of the dynamic linker enabled unless one also 
> uses a custom build of that tool.
>
> Other than these default paths, no additional ones are set up on my 
> system.

Ok, GCC's paths are fine.  I thought you meant you had added, say, -I 
/usr/local/chicken/include and -L /usr/local/chicken/lib to every 
compilation anywhere, regardless of whether you're using Chicken or 
not.  I don't think it would be a good idea to have such directives when 
Chicken is building Chicken.

> > [...] If you had stuff lying around in your source tree from an old 
> > Autoconf build, that could be the culprit.
>
> I made a fresh copy of my darcs tree using darcs get to use it as the 
> source tree for the CMake build.

Hm, well, I'll put the INCLUDE and LIB bulletproofing in, such as I 
can.  Then we'll see.

> > [...] 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'll do that if it actually annoys me and if I have too much time for 
> constructing a minimal example of the problem. csc -static ... works 
> perfectly as it should even though I removed chicken-static and 
> csi-static. And I can live with a build producing strange executables 
> which I just throw away.

Ok, but realize, that doesn't help either Chicken or CMake get better, 
nor attract new users.  Next guy that comes along has the same problem, 
doesn't think to report them, calls Chicken or CMake a bad project, goes 
on to something else.  But really neither one is a bad project, they're 
open source projects.  I think the cost of using open source is doing 
small amounts of testing and submitting some bug reports.  Of course we 
each have to decide week to week what we're willing to do.  I just don't 
think, "Eh, it's just a little broken, no big deal" is very good for 
open source.  People often tout that open source is superior to closed 
source because bugs get fixed faster.  It would be depressing if certain 
aspects of the culture actually made it work in reverse!


Cheers,
Brandon Van Every