Re: [Mono-list] MacOS packages.
Ok, after alot more digging and experimenting, there is a ton of work to make this like the Java implementation, which, I still think is the 'correct' answer, but it's going to have to be the longer term answer. I don't think we can get it all done between now and the next release without more time and resource than I can dedicate to it. Here is what I would propose: Phase I: A .pkg installer that installs Mono and Mcs to /usr/local/, with a detailed description on how to properly set up the environment to use /usr/local/bin. This package would use glib statically linked, to avoid the need to also deploy glib to the users machine. Seperate .pkg installers would also be made available for XSP, MOD_MONO, GTK# and any other optional elements of Mono. Phase II: A process to automatically build the Mono and Mcs into a standalone MonoVM.Framework that installs to /Library/ with an installer (.pkg) that aliases the core commands, mono, mint, mcs, and the others to /usr/bin. I know that Apple reserves the right to the /usr/bin directory, but from an Apple 'it just works' perspective, it is the only place to put them. With Phase II, it would be feasable to ship .app bundles that uses an exectuable that calls the /usr/bin/mono framework and launches just like any other OS X application. Ultimately, this opens the door for Mono to provide the same level of application parity as Java, Cocoa (Objective C), or Carbon (C/C++). The problem with the second is that as far as I can tell, it would require XCode projects to build the framework, and all the associated dylibs. creating that project is going to be time consuming, and it will require updating to be kept in sync with the ./configure make process. I've got most of Phase I complete at this point, I'm doing some testing now, and should have a working deliverable in the next few days. Once that is completed, I'll begin the long and arduous process of doing Phase II. Andy Satori On Feb 25, 2004, at 9:22 AM, Urs Muff wrote: This is great! Please publish the Xcode projects and scripts you use to make the package and framework so others can build it from CVS. Miguel or myself will check them into CVS in case you don't have access. - Urs -Original Message- From: Andy Satori [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 25, 2004 7:21 AM To: Urs Muff Cc: 'Miguel de Icaza'; [EMAIL PROTECTED] Subject: Re: [Mono-list] MacOS packages. 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 well). 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. Andy 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 links to /System/Library/Framework/JavaVM.Framework/Version/1.4.2/Command/java. -- We only have to create soft links for stuff main executables, but not necessary the .exe assemblies since those are just .Net assemblies unless we have some .exe Mono launcher in /etc/... as discussed many times on this list. As for the version: that is the framework version not the assembly version. The GAC is fine and no problem, but Apple is talking about the executables (mono,mint) dynamic libraries (libmono.dylib, ...) and the C-headers, and that has a standard folder structure. - URS C. MUFF -Original Message- From: Miguel de Icaza [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 24, 2004 7:43 PM To: Urs C Muff Cc: Andy Satori; [EMAIL PROTECTED] Subject: Re: [Mono-list] MacOS packages. Hello, 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 /System/Library/Frameworks/MonoVM.Framework/Versions/0.30/Assemblies where there is a link pointing there @ /System/Library/Frameworks/MonoVM.Framework/Assemblies. 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 path... I think you just build mono with a prefix of: /System/Library/Frameworks/MonoVM.Framework And just copy anything that is installed in the bin/ subdirectory to /usr/bin. As for the versioning: we will be taking care of library versions in a different way (the GAC approach) smime.p7s Description: S/MIME cryptographic signature
Re: [Mono-list] MacOS packages.
On Tue, 2004-03-02 at 16:58, Andy Satori wrote: The problem with the second is that as far as I can tell, it would require XCode projects to build the framework, and all the associated dylibs. creating that project is going to be time consuming, and it will require updating to be kept in sync with the ./configure make process. Can you explain why this is? I'm not at all familiar with OS X development, but you can accomplish a lot with makefile mojo ... Peter -- Peter Williams [EMAIL PROTECTED] [Ninjas] are cool; and by cool, I mean totally sweet. -- REAL Ultimate Power ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] MacOS packages.
Andy Satori wrote: Phase I: A .pkg installer that installs Mono and Mcs to /usr/local/, with a detailed description on how to properly set up the environment to use /usr/local/bin. This package would use glib statically linked, to avoid the need to also deploy glib to the users machine. I know this is always a topic of religious war, but... /usr/local is in the default compiler path. Unless you're committing to always maintaining all of mono's dependencies, keeping them up-to-date, and making them compatible with other packaging systems, you're going to end up causing conflicts with things like fink and opendarwin that expect things in different places. IMHO, /usr/local is for the *local* administrator to put things, not 3rd-party packagers. I would suggest /opt/mono or somesuch instead. If people want to use those binaries for their own projects, they can with CFLAGS and LDFLAGS, without polluting the default compiler path. At the very least, put them somewhere out of the way and ask if they want you to symlink them to /usr/local. The problem with the second is that as far as I can tell, it would require XCode projects to build the framework, and all the associated dylibs. creating that project is going to be time consuming, and it will require updating to be kept in sync with the ./configure make process. You can make frameworks manually, by changing things around after building using install_name_tool (I do this with the Qt3 packages I made). Generally you would do something like: install -d /Library/Frameworks/MonoVM.framework/Versions/A/Headers cp -a /mono/root/include/* \ /Library/Frameworks/MonoVM.framework/Versions/A/Headers cp /mono/root/lib/libmono.dylib \ /Library/Frameworks/MonoVM.framework/Versions/A/MonoVM ln -sf A/MonoVM /Library/Frameworks/MonoVM.framework/MonoVM ln -sf A/Headers /Library/Frameworks/MonoVM.framework/Headers install_name_tool -id \ /Library/Frameworks/MonoVM.framework/Versions/A/MonoVM ...or something along those lines. There's more to it for any reasonably complicated framework, but you get the idea. -- Benjamin Reed, a.k.a. RangerRick [EMAIL PROTECTED] / http://ranger.befunk.com/ Now Playing: Hyperballad (Brodsky Quartet Version) by Bjrk ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] MacOS packages.
Hello, Phase I: A .pkg installer that installs Mono and Mcs to /usr/local/, with a detailed description on how to properly set up the environment to use /usr/local/bin. This package would use glib statically linked, to avoid the need to also deploy glib to the users machine. I also agree with the other poster that /usr/local should be reserved for the local system administrator. As I said previously, I think we should stick stuff in /Library, and install links in /usr/bin for the programs. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] MacOS packages.
I agree, /Library has to be it's ultimate home, but right now, OS X is a disaster regarding anything else. Fink uses /sw/ (huh?) darwinports uses /opt/ and /opt/local/ (huh? further). I want to get everything into the Framework under /Library, but the default build process right now makes that a time consuming task. If you are talking 2-3 weeks until the next release, I'll never get it done in time. If it's 2 months, I might pull it off :-). I simply don't have the copious spare time to to it, and my day job frowns upon Open Source, so I have to work at it in my off hours :-). That said, I;m going in the direction, and Benjamin had a couple of pointers that should help quite a bit, but it's still going to take time. Please bear in mind, that while I have a reasonable Unix comfort level, I'm by no means an expert, every flavor I've ever used treats /usr/local and /opt differently. Exacerbating that issue is that I've spent the last 10 years doing Windows development. So I'm very flexible regarding this, and the /usr/local was mostly done because that seems to be where most of the .pkg's I've installed put things. I'll adjust accordingly. Andy On Mar 2, 2004, at 7:20 PM, Miguel de Icaza wrote: Hello, Phase I: A .pkg installer that installs Mono and Mcs to /usr/local/, with a detailed description on how to properly set up the environment to use /usr/local/bin. This package would use glib statically linked, to avoid the need to also deploy glib to the users machine. I also agree with the other poster that /usr/local should be reserved for the local system administrator. As I said previously, I think we should stick stuff in /Library, and install links in /usr/bin for the programs. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list smime.p7s Description: S/MIME cryptographic signature
RE: [Mono-list] MacOS packages.
If you actually look at /usr/bin/javac, /usr/bin/java, those are soft links to /System/Library/Framework/JavaVM.Framework/Version/1.4.2/Command/java. -- We only have to create soft links for stuff main executables, but not necessary the .exe assemblies since those are just .Net assemblies unless we have some .exe Mono launcher in /etc/... as discussed many times on this list. As for the version: that is the framework version not the assembly version. The GAC is fine and no problem, but Apple is talking about the executables (mono,mint) dynamic libraries (libmono.dylib, ...) and the C-headers, and that has a standard folder structure. - URS C. MUFF -Original Message- From: Miguel de Icaza [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 24, 2004 7:43 PM To: Urs C Muff Cc: Andy Satori; [EMAIL PROTECTED] Subject: Re: [Mono-list] MacOS packages. Hello, 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 /System/Library/Frameworks/MonoVM.Framework/Versions/0.30/Assemblies where there is a link pointing there @ /System/Library/Frameworks/MonoVM.Framework/Assemblies. 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 path... I think you just build mono with a prefix of: /System/Library/Frameworks/MonoVM.Framework And just copy anything that is installed in the bin/ subdirectory to /usr/bin. As for the versioning: we will be taking care of library versions in a different way (the GAC approach) ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] MacOS packages.
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 well). 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. Andy 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 links to /System/Library/Framework/JavaVM.Framework/Version/1.4.2/Command/java. -- We only have to create soft links for stuff main executables, but not necessary the .exe assemblies since those are just .Net assemblies unless we have some .exe Mono launcher in /etc/... as discussed many times on this list. As for the version: that is the framework version not the assembly version. The GAC is fine and no problem, but Apple is talking about the executables (mono,mint) dynamic libraries (libmono.dylib, ...) and the C-headers, and that has a standard folder structure. - URS C. MUFF -Original Message- From: Miguel de Icaza [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 24, 2004 7:43 PM To: Urs C Muff Cc: Andy Satori; [EMAIL PROTECTED] Subject: Re: [Mono-list] MacOS packages. Hello, 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 /System/Library/Frameworks/MonoVM.Framework/Versions/0.30/Assemblies where there is a link pointing there @ /System/Library/Frameworks/MonoVM.Framework/Assemblies. 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 path... I think you just build mono with a prefix of: /System/Library/Frameworks/MonoVM.Framework And just copy anything that is installed in the bin/ subdirectory to /usr/bin. As for the versioning: we will be taking care of library versions in a different way (the GAC approach) ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] MacOS packages.
This is great! Please publish the Xcode projects and scripts you use to make the package and framework so others can build it from CVS. Miguel or myself will check them into CVS in case you don't have access. - Urs -Original Message- From: Andy Satori [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 25, 2004 7:21 AM To: Urs Muff Cc: 'Miguel de Icaza'; [EMAIL PROTECTED] Subject: Re: [Mono-list] MacOS packages. 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 well). 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. Andy 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 links to /System/Library/Framework/JavaVM.Framework/Version/1.4.2/Command/java. -- We only have to create soft links for stuff main executables, but not necessary the .exe assemblies since those are just .Net assemblies unless we have some .exe Mono launcher in /etc/... as discussed many times on this list. As for the version: that is the framework version not the assembly version. The GAC is fine and no problem, but Apple is talking about the executables (mono,mint) dynamic libraries (libmono.dylib, ...) and the C-headers, and that has a standard folder structure. - URS C. MUFF -Original Message- From: Miguel de Icaza [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 24, 2004 7:43 PM To: Urs C Muff Cc: Andy Satori; [EMAIL PROTECTED] Subject: Re: [Mono-list] MacOS packages. Hello, 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 /System/Library/Frameworks/MonoVM.Framework/Versions/0.30/Assemblies where there is a link pointing there @ /System/Library/Frameworks/MonoVM.Framework/Assemblies. 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 path... I think you just build mono with a prefix of: /System/Library/Frameworks/MonoVM.Framework And just copy anything that is installed in the bin/ subdirectory to /usr/bin. As for the versioning: we will be taking care of library versions in a different way (the GAC approach) ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] MacOS packages.
What about GTK# ? Is that Mono built with ICU, Andy ? What are you doing with XCode ? Erik ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] MacOS packages.
At this point, I'm packaging GTK#, XSP and MOD_MONO as seperate packages. On the ICU (and GC) front, I currently build without either, but once I get all the foundation in place, I'll add them. With XCode, I currently have a C# language filter defined so that XCode can parse the functions and color C# files. I also have a Makefile based project template for building a C# application in XCode. I'm now working on enhancing that to be a part of the XCode native build system, instead of the old Project Builder, jam based, build system. This will improve the error parsing and display, as well as allow you to use the much more powerful Info panels in XCode to set up your build environments. After that, it is my intent to build a library of templates for XCode to setup your basic projects, much like VS.NET. Hopefully by that time, Apple will have updated XCode to make it easier to integrate external debuggers into XCode, and I'll be able to add that. Andy On Feb 25, 2004, at 10:54 AM, Erik Dasque wrote: What about GTK# ? Is that Mono built with ICU, Andy ? What are you doing with XCode ? Erik ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] MacOS packages.
Andy, The xcode stuff sounds great. Are you packaging 0.30.2 or a cvs build ? I don't believe the ppc fix is in the releases yet. I have found that many applications crash (Bus error) without it thus far (including a lot of GTK# apps). Do you use the interpreter only ? Also, I believe ICU is needed to run monodevelop, wink, wink. Erik On Feb 25, 2004, at 11:27 AM, Andy Satori wrote: At this point, I'm packaging GTK#, XSP and MOD_MONO as seperate packages. On the ICU (and GC) front, I currently build without either, but once I get all the foundation in place, I'll add them. With XCode, I currently have a C# language filter defined so that XCode can parse the functions and color C# files. I also have a Makefile based project template for building a C# application in XCode. I'm now working on enhancing that to be a part of the XCode native build system, instead of the old Project Builder, jam based, build system. This will improve the error parsing and display, as well as allow you to use the much more powerful Info panels in XCode to set up your build environments. After that, it is my intent to build a library of templates for XCode to setup your basic projects, much like VS.NET. Hopefully by that time, Apple will have updated XCode to make it easier to integrate external debuggers into XCode, and I'll be able to add that. Andy On Feb 25, 2004, at 10:54 AM, Erik Dasque wrote: What about GTK# ? Is that Mono built with ICU, Andy ? What are you doing with XCode ? Erik ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] MacOS packages.
At the moment, my primary installation is a CVS build. I did all the dependancy work and checks on a clean OS X install (gotta love firewire external drives) and it's using 0.30.2, as it's a quicker and easier build process on a virgin machine. Once I have the basics established, I'll bring it all up to date, including updating to the newly releasesd GLib 2.3.3. Andy On Feb 25, 2004, at 11:37 AM, Erik Dasque wrote: Andy, The xcode stuff sounds great. Are you packaging 0.30.2 or a cvs build ? I don't believe the ppc fix is in the releases yet. I have found that many applications crash (Bus error) without it thus far (including a lot of GTK# apps). Do you use the interpreter only ? Also, I believe ICU is needed to run monodevelop, wink, wink. Erik ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] MacOS packages - GTK#.
I replaced all references to mono to point to mint in the makefiles. If you're using 0.30.x, you probably don't have the ppc fix and mcs.exe (running with mono, the JIT) as well as other .exe processes (gapi comes to mind) will die. Erik On Feb 25, 2004, at 11:54 AM, Elfred Pagán wrote: This is a little offtopic, but since you mention GTK# I tried to compile GTK# early this week and the compilation through an exception and since mcs doesn't support exception handling yet, the process crashed. Are you doing anything special to compile GTK#? On Feb 25, 2004, at 12:27 PM, Andy Satori wrote: At this point, I'm packaging GTK#, XSP and MOD_MONO as seperate packages. On the ICU (and GC) front, I currently build without either, but once I get all the foundation in place, I'll add them. With XCode, I currently have a C# language filter defined so that XCode can parse the functions and color C# files. I also have a Makefile based project template for building a C# application in XCode. I'm now working on enhancing that to be a part of the XCode native build system, instead of the old Project Builder, jam based, build system. This will improve the error parsing and display, as well as allow you to use the much more powerful Info panels in XCode to set up your build environments. After that, it is my intent to build a library of templates for XCode to setup your basic projects, much like VS.NET. Hopefully by that time, Apple will have updated XCode to make it easier to integrate external debuggers into XCode, and I'll be able to add that. Andy On Feb 25, 2004, at 10:54 AM, Erik Dasque wrote: What about GTK# ? Is that Mono built with ICU, Andy ? What are you doing with XCode ? Erik ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list Elfred Pagán ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] MacOS packages.
Hey guys, Given that the Mono port for MacOS is progressing rapidly [1], I would like the next release of Mono to be available as an easy-to-use .dmg file. Can someone who understand this explain what do I have to do? [1] the only missing feature am aware of is exception handling. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] MacOS packages.
This depends upon if you want a 'native' solution, or a Fink, or a DarwinPorts solution. I personally prefer native solutions, as they don't require any 3rd party tools, but it means packaging all of the dependancies as well. The native solution would be to build Package via the Apple Developer Tools Package Builder, then place it in a disk image, gzip the image and that's your installer. The other solutions require that either the Fink client or the DarwinPorts tools be installed and then the user can use those installation systems, which are more like the Linux RPM, or Apt Get tools. This is fine, but it puts things in funny locations, like /sw/bin /sw/lib or /opt/, making your documentation a little bit odd. I'd be happy to work on a full installer package if that's of interest. It's not to terribly complex, and it ties into my work on integrating Mono (mcs) into XCode. Andy On Feb 24, 2004, at 1:44 PM, Miguel de Icaza wrote: Hey guys, Given that the Mono port for MacOS is progressing rapidly [1], I would like the next release of Mono to be available as an easy-to-use .dmg file. Can someone who understand this explain what do I have to do? [1] the only missing feature am aware of is exception handling. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] MacOS packages.
A native solution is definitely preferable. Even if Fink/DarwinPorts solutions are available, there are many Mac developers who will be interested in Mono who aren't interested in becoming familiar with Fink. I would also be interested in helping get together a full installer. However, if it's just creation of an easily-distributable dmg file that you need, the following link might be of interest, as it's very simple to programmatically create the dmg image and add files to it during your build: http://www.aplawrence.com/Bofcusm/2011.html Bo Andy Satori wrote: This depends upon if you want a 'native' solution, or a Fink, or a DarwinPorts solution. I personally prefer native solutions, as they don't require any 3rd party tools, but it means packaging all of the dependancies as well. The native solution would be to build Package via the Apple Developer Tools Package Builder, then place it in a disk image, gzip the image and that's your installer. The other solutions require that either the Fink client or the DarwinPorts tools be installed and then the user can use those installation systems, which are more like the Linux RPM, or Apt Get tools. This is fine, but it puts things in funny locations, like /sw/bin /sw/lib or /opt/, making your documentation a little bit odd. I'd be happy to work on a full installer package if that's of interest. It's not to terribly complex, and it ties into my work on integrating Mono (mcs) into XCode. Andy On Feb 24, 2004, at 1:44 PM, Miguel de Icaza wrote: Hey guys, Given that the Mono port for MacOS is progressing rapidly [1], I would like the next release of Mono to be available as an easy-to-use .dmg file. Can someone who understand this explain what do I have to do? [1] the only missing feature am aware of is exception handling. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] MacOS packages.
OK, following up my own post and thoughts. I went ahead and installed OS X 10.3 on an external FW drive, and just built a ground up Mono install using pkg-config 0.15.0, glib-2.3.1, gettext 0.11.5, and mono-0.30.1. And I'm getting ready to assemble the .pkg files for those installations. The question now becomes, where to put them... On a fresh installation of OS X, /usr/local/bin is not in the path. Everything lives in /usr/bin, including java, javac, php, ruby, and python. Based upon that, we have the option of installing Mono and it's dep's into /usr/ /usr/local/ or /opt/. For the average user, installing it to /usr/ means that it will just magically work. The other alternative is to write a shell script to alter the systemwide environment variables, but this would be overwritten by every .x.x patch to the OS. With the change to bash, we could alter it for the terminal windows, but spawned tasks would not have the correct environment by default. Looking at the way that Apple integrated Java into the operating system, it looks like the proper way to do this would be to go to /usr/ as this would allow Mono development to build applications that are deployed in name.app bundles just like Java applications and be executable in the same fashion, giving Mono apps the same level of system parity as Java. The only negative I see with this is that it might conflict with other versions of glib-2 or gettext on the system. It might give some strange interactions with DarwinPorts or Fink applications. Does anyone have any thoughts? Andy Satori On Feb 24, 2004, at 2:37 PM, Andy Satori wrote: This depends upon if you want a 'native' solution, or a Fink, or a DarwinPorts solution. I personally prefer native solutions, as they don't require any 3rd party tools, but it means packaging all of the dependancies as well. The native solution would be to build Package via the Apple Developer Tools Package Builder, then place it in a disk image, gzip the image and that's your installer. The other solutions require that either the Fink client or the DarwinPorts tools be installed and then the user can use those installation systems, which are more like the Linux RPM, or Apt Get tools. This is fine, but it puts things in funny locations, like /sw/bin /sw/lib or /opt/, making your documentation a little bit odd. I'd be happy to work on a full installer package if that's of interest. It's not to terribly complex, and it ties into my work on integrating Mono (mcs) into XCode. Andy On Feb 24, 2004, at 1:44 PM, Miguel de Icaza wrote: Hey guys, Given that the Mono port for MacOS is progressing rapidly [1], I would like the next release of Mono to be available as an easy-to-use .dmg file. Can someone who understand this explain what do I have to do? [1] the only missing feature am aware of is exception handling. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
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 /System/Library/Frameworks/MonoVM.Framework/Versions/0.30/Assemblies where there is a link pointing there @ /System/Library/Frameworks/MonoVM.Framework/Assemblies. 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 path... - Urs On Feb 24, 2004, at 5:11 PM, Andy Satori wrote: OK, following up my own post and thoughts. I went ahead and installed OS X 10.3 on an external FW drive, and just built a ground up Mono install using pkg-config 0.15.0, glib-2.3.1, gettext 0.11.5, and mono-0.30.1. And I'm getting ready to assemble the .pkg files for those installations. The question now becomes, where to put them... On a fresh installation of OS X, /usr/local/bin is not in the path. Everything lives in /usr/bin, including java, javac, php, ruby, and python. Based upon that, we have the option of installing Mono and it's dep's into /usr/ /usr/local/ or /opt/. For the average user, installing it to /usr/ means that it will just magically work. The other alternative is to write a shell script to alter the systemwide environment variables, but this would be overwritten by every .x.x patch to the OS. With the change to bash, we could alter it for the terminal windows, but spawned tasks would not have the correct environment by default. Looking at the way that Apple integrated Java into the operating system, it looks like the proper way to do this would be to go to /usr/ as this would allow Mono development to build applications that are deployed in name.app bundles just like Java applications and be executable in the same fashion, giving Mono apps the same level of system parity as Java. The only negative I see with this is that it might conflict with other versions of glib-2 or gettext on the system. It might give some strange interactions with DarwinPorts or Fink applications. Does anyone have any thoughts? Andy Satori On Feb 24, 2004, at 2:37 PM, Andy Satori wrote: This depends upon if you want a 'native' solution, or a Fink, or a DarwinPorts solution. I personally prefer native solutions, as they don't require any 3rd party tools, but it means packaging all of the dependancies as well. The native solution would be to build Package via the Apple Developer Tools Package Builder, then place it in a disk image, gzip the image and that's your installer. The other solutions require that either the Fink client or the DarwinPorts tools be installed and then the user can use those installation systems, which are more like the Linux RPM, or Apt Get tools. This is fine, but it puts things in funny locations, like /sw/bin /sw/lib or /opt/, making your documentation a little bit odd. I'd be happy to work on a full installer package if that's of interest. It's not to terribly complex, and it ties into my work on integrating Mono (mcs) into XCode. Andy On Feb 24, 2004, at 1:44 PM, Miguel de Icaza wrote: Hey guys, Given that the Mono port for MacOS is progressing rapidly [1], I would like the next release of Mono to be available as an easy-to-use .dmg file. Can someone who understand this explain what do I have to do? [1] the only missing feature am aware of is exception handling. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] MacOS packages.
Hello, 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 /System/Library/Frameworks/MonoVM.Framework/Versions/0.30/Assemblies where there is a link pointing there @ /System/Library/Frameworks/MonoVM.Framework/Assemblies. 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 path... I think you just build mono with a prefix of: /System/Library/Frameworks/MonoVM.Framework And just copy anything that is installed in the bin/ subdirectory to /usr/bin. As for the versioning: we will be taking care of library versions in a different way (the GAC approach) ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] MacOS packages.
Yes, you are correct, though I suspect that's going to require some manual rebuilding of Mono itself. Andy On Feb 24, 2004, at 7:34 PM, Urs C Muff wrote: 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 /System/Library/Frameworks/MonoVM.Framework/Versions/0.30/Assemblies where there is a link pointing there @ /System/Library/Frameworks/MonoVM.Framework/Assemblies. 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 path... - Urs On Feb 24, 2004, at 5:11 PM, Andy Satori wrote: OK, following up my own post and thoughts. I went ahead and installed OS X 10.3 on an external FW drive, and just built a ground up Mono install using pkg-config 0.15.0, glib-2.3.1, gettext 0.11.5, and mono-0.30.1. And I'm getting ready to assemble the .pkg files for those installations. The question now becomes, where to put them... On a fresh installation of OS X, /usr/local/bin is not in the path. Everything lives in /usr/bin, including java, javac, php, ruby, and python. Based upon that, we have the option of installing Mono and it's dep's into /usr/ /usr/local/ or /opt/. For the average user, installing it to /usr/ means that it will just magically work. The other alternative is to write a shell script to alter the systemwide environment variables, but this would be overwritten by every .x.x patch to the OS. With the change to bash, we could alter it for the terminal windows, but spawned tasks would not have the correct environment by default. Looking at the way that Apple integrated Java into the operating system, it looks like the proper way to do this would be to go to /usr/ as this would allow Mono development to build applications that are deployed in name.app bundles just like Java applications and be executable in the same fashion, giving Mono apps the same level of system parity as Java. The only negative I see with this is that it might conflict with other versions of glib-2 or gettext on the system. It might give some strange interactions with DarwinPorts or Fink applications. Does anyone have any thoughts? Andy Satori On Feb 24, 2004, at 2:37 PM, Andy Satori wrote: This depends upon if you want a 'native' solution, or a Fink, or a DarwinPorts solution. I personally prefer native solutions, as they don't require any 3rd party tools, but it means packaging all of the dependancies as well. The native solution would be to build Package via the Apple Developer Tools Package Builder, then place it in a disk image, gzip the image and that's your installer. The other solutions require that either the Fink client or the DarwinPorts tools be installed and then the user can use those installation systems, which are more like the Linux RPM, or Apt Get tools. This is fine, but it puts things in funny locations, like /sw/bin /sw/lib or /opt/, making your documentation a little bit odd. I'd be happy to work on a full installer package if that's of interest. It's not to terribly complex, and it ties into my work on integrating Mono (mcs) into XCode. Andy On Feb 24, 2004, at 1:44 PM, Miguel de Icaza wrote: Hey guys, Given that the Mono port for MacOS is progressing rapidly [1], I would like the next release of Mono to be available as an easy-to-use .dmg file. Can someone who understand this explain what do I have to do? [1] the only missing feature am aware of is exception handling. ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
