On May 15, 2007, at 7:35 AM, Brandon Van Every wrote:
>
> At a first go, read INSTALL-CMake.txt and try to build Chicken on
> your Mac OS X. Then see the bugtracker ticket I've just added
> about universal binaries.
http://trac.callcc.org/ticket/214
>
>
(I tried putting this in trac, but it keeps getting rejected as spam.
Huh?)
I installed cmake, and figured out how to make it produce an Xcode
project file. Even though CMake came up with an option to specify
which build architectures to use, the generated project file only did
powerpc. After adding i386, I tried compiling... and it didn't work
-- posixwin.c was included in the source, and, for some reason, it
took 5 minutes for Xcode to respond to /anything/ -- which is NOT
normal for it. I gave up fighting that before I got any results.
I wouldn't expect the current CMake build to generate universal binaries just by adding flags. Currently we use a TRY_RUN with CStackGrowsDownward.c, and this should cause disaster when cross-compiling. This is noted in the ticket about universal binaries above.
(I
used cmake 2.4p6, which is what was in my package system. Dunno if
there's a newer release that produces a project that doesn't cause
the issue.)
CMake 2.4.6 is the most recent stable release. To get more recent than that, you'd need to compile CMake from CVS sources. I am not presently up on CMake XCode issues so I don't know if that would be profitable for you. You could look in the CMake bug tracker or mailing list archives to see what they have to say about XCode.
Next, I tried using cmake to generate makefiles. It came up with the
same build architecture option, but, just as with the Xcode option,
seems to ignore it.
Initial impression of cmake after 10 minutes: I don't like it. It
makes Xcode projects that do their best to break Xcode.
It's not CMake's fault that we haven't implemented support for universal binaries yet. As for XCode, I don't know enough about it to separate CMake issues from Chicken issues.
The makefiles it generates hide too much;
That's the price you pay for a build system generator that works on all platforms. You were expecting the clarity of a hand-crafted makefile?
I had to check ps and, after tracking
down where it was putting object files, use file to confirm that it
was only producing powerpc code.
Well, things that are broken aren't terribly likeable.
And it colorizes stuff! Icky.
That's not important.
Please don't get rid of the autoconf and automake and libtool way of
building. (Which I like to use in decreasing order. autoconf is
great. automake is ugly and I try to avoid using it for my own
projects, preferring autoconf and hand-written makefiles. libtool
is... I've already said what I feel about that. But the alternatives
seem to be just as bad.) It's still better than cmake, at least for me.
On the other hand, you said you put 10 minutes of work into CMake. That's enough to indicate there are problems, and thanks for doing it! It is not, however, enough to make a case for splitting the energies of the community between Autoconf and CMake. What we'd like is for Mac people to work on the CMake build so that these issues get fixed and go away. I'm point man on CMake, but I can only do so much because I don't have a Mac.
Cheers,
Brandon Van Every