RELEASE on March, 1st !!!
Marc-Antoine Parent
maparent at mac.com
Tue Feb 10 19:43:10 CET 2004
> 1. performace issues [with gcc3]
> It looks like we can solve them for some platforms (intel), at
> least temporarily - and hoping that the future gcc release will be
> better. The things are "all right" out-of-box for other ones
> (e.g. apple). DO I SEE IT RIGHT?
As for Apple, I can say that there was a substantial drop in efficiency
between gcc 2.95 and 3.1. _some_ of that was regained with 3.3, but I
cannot say that we have a satisfying compiler yet. I may make a few
tests with an unreleased 3.3.1 I have built from Apple sources, if
there is an interest.
> 3. packaging
> Probably the bulkiest chunk of work. I'm afraid we might miss
> information about Windows (apparently, the Windows packaging
> business is going to change hands now). MacOS X & other platforms
> (aka FreeBSD) seem to be a bit ad'hoc as well. WE WOULD WELCOME ANY
> INPUT - HELP, INFORMATION, DOCUMENTATION HERE!!! Credits will be
> of course given..
I have sent detailed instructions to the list before. Look for the
title: "Release (OSX)"
The packaging still involves many manual steps, and should be further
automated, but packaging material does exist. It is not integrated in
the CVS at this point, which we may want to do.
We cannot really automate it at this point, as the packaging tool uses
absolute paths in a binary file (!!!) to point to the mozart install
location (which I hardcoded to /usr/local/oz) and the resources
location (i.e. LICENSE.html and ReadMe.rtf, which should live in the
source folder somewhere... and that being hardcoded is simply stupid.)
Now, I must say we have a harder issue: Do we build for Panther (10.3)
only, stay compatible with Jaguar (10.2), etc. (I am not sure we are
even still compatible with 10.1, and I would advise against even
trying.)
We may have to consider separate versions. For example, Mozart uses
dlopen, etc. which were not in Jaguar, so we used a compatibility shim
(dlcompat); it became standard in Panther. I am not sure that, if we
link against dlcompat, mozart will work properly with Panther (though
it should.) The reverse is of course not true.
libbz2 and libiconv, both needed by mozart-gtk, also made their way
into Panther.
In other words, some testing and some hard decisions should be done. I
myself would favour separate packages, but it adds to the workload.
While still on the Panther issue, we also need to add a few lines to
configuration of platform/wish:
The Makefile.in uses pbxbuild in two places. This was renamed to
xcodebuild in Panther. we should check which of these, if any, was
installed. (It would live in /usr/bin )
I am not familiar with configure, but maybe I could attempt writing
this.
> darwin-ppc
> 997 (hard-wired name of compiler ('gcc') in oztool.sh)
Good point, we now have the xlc option. Did anyone try building mozart
with it?
Marc-Antoine Parent
More information about the mozart-hackers
mailing list