[Mono-list] MacOS packages.
Wed, 25 Feb 2004 09:21:21 -0500
Urs is correct, after some more digging, it's the 'way' to go. it's
going to take me a couple of days to cleanup my own system to get all
this built and tested (wish I had another machine for this... oh
I've got the packages and base installer's built, I just need to run
through and tweak them into frameworks. This will also make them much
easier to install and manage in the future.
On Feb 25, 2004, at 8:21 AM, Urs Muff wrote:
> If you actually look at /usr/bin/javac, /usr/bin/java, those are soft
> --> We only have to create soft links for stuff main executables, but
> necessary the .exe assemblies since those are just .Net assemblies
> unless we
> have some .exe Mono launcher in /etc/... as discussed many times on
> As for the version: that is the framework version not the assembly
> The GAC is fine and no problem, but Apple is talking about the
> (mono,mint) dynamic libraries (libmono.dylib, ...) and the C-headers,
> that has a standard folder structure.
> - URS C. MUFF
> -----Original Message-----
> From: Miguel de Icaza [mailto:email@example.com]
> Sent: Tuesday, February 24, 2004 7:43 PM
> To: Urs C Muff
> Cc: Andy Satori; firstname.lastname@example.org
> Subject: Re: [Mono-list] MacOS packages.
>> Well actually I agree that the shell scripts 'mono' and 'mcs' might
>> live in /usr/bin, but I would create a Framework and put it in
>> /System/Library/Frameworks/MonoVM.Framework the same way as
>> /System/Library/Frameworks/JavaVM.Framework is placed (look at the
>> folder structure within the framework to see how Apple is structuring
>> such a beast).
>> But the .Net assemblies should live in
>> where there is a link pointing there @
>> That would conform with Apple's standard much better: I don't know how
>> we would have to build mono to include those in the assembly load
> I think you just build mono with a prefix of:
> And just copy anything that is installed in the bin/ subdirectory to
> As for the versioning: we will be taking care of library versions in a
> different way (the GAC approach)