[Top][All Lists]

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

Re: [Chicken-users] alternate build tools

From: Patrick Brannan
Subject: Re: [Chicken-users] alternate build tools
Date: Mon, 3 Oct 2005 10:47:58 -0500

I built chicken with CMake on Windows (free ms tools) this weekend. Building the basic project was easy. That being said I am not sure what I think about CMake itself. Here's the issue.

In CMake you set variable to contain source files. And on those source files you can set properties. It looks something like this:

SET(CHICKEN_LIB_SOURCES runtime.c library.c ...)

SET(CHICKEN_EXE_SOURCES chicken.c support.c ...)
TARGET_LINK_LIBRARIES(chicken_d chicken)

This is about all it takes to create a build file that builds a working dynamically linked exe called chicken_d.exe. It really is fantastically simple. But it also makes some assumptions that I haven't worked around cleanly.

1. Note that I had to name the exe chicken_d. I could easily rename it in a later step, but the point is that CMake doesn't seem to easily support custom file names. Files will be named for the target plus the appropriate extension.

2. Setting source file properties is a global operation where the last set wins. So I haven't found an easy way to combine both static and dynamic linking. I even tried listing the source files twice and setting properties differently on each listing. The file sets seem to be global entities that can accept only one set of properties.

On 10/3/05, Brandon J. Van Every <address@hidden > wrote:
Tony Garnock-Jones wrote:

>Ashley Bone wrote:
>>The most common settings are handled by scons (for instance, things like
>>-fPIC for gcc or /MD for msvc).
>>Special flags like optimizations and so forth have to be explicitly
>>added, but I think that's true of any tool.
>The crucial question is going to be libtool-type support. How well do
>any of these tools cope with building different styles of shared
CMake has built some pretty huge software systems like the Visualization
Toolkit so I don't see this as a big deal.  I'm more
worried about the quality of the MinGW support.  I heard "somewhere in
passing" that CMake can handle MinGW now, but the CMake webpage and the
docs still don't explicitly mention it.  So that makes me worry that
it's not a well-exercised target (gee, much like Chicken and so many
other open source projects.)

Still, I cannot worry unduly.  I've already made the decision that I
will attempt CMake.  But, I have to go get a job or get tossed out of my
apartment, so I can't put much effort into this right now.  If it's
easy, then suddenly I'll say Hey Presto.  If it's hard, either because
of CMake or the Chicken architecture itself, then I probably won't get
it done.  Like, if I had to bang on something for a month to get it to
work, I wouldn't bother.  I'd just concentrate on other projects of mine
that are easier to make progress on.

If anyone wants to team up with me to try to bang out a CMake, that
would be welcome.  More likely to stay focused that way.

In any event, realistically it's gonna be CMake or SCons.  I doubt
anyone believes that Ant ant-contrib CC Task is going to be pleasant.
The only reason I brought it up is because I'm doing Eclipse stuff.
Anyways, if the SCons crowd wants to get together and bang something
out, and it's easy to do, then by all means go for it.  But that's not
the road I will travel for now.  I believe CMake is the ticket, as it's
meant to replace GNU Autotools and be cross-platform.  It doesn't add a
language dependency, so if all else is equal between CMake and SCons,
that's a win.

It's all going to be about actually attempting a build, since it seems
none of us really have the experience at these tools to know what they
can handle.

Brandon J. Van Every
    (cruise (director (of SeaFunc)
            '(Seattle Functional Programmers)))

Chicken-users mailing list

reply via email to

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