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