Slashdot Mirror

← Back to Stories (view on slashdot.org)

Mono Adds Mac OS X Package

Posted by timothy on from the for-your-conversion dept.

Good news for those of you who've went through the pain of trying to get Mono installed on Mac OS X: the team has quietly added a Mac OS X package. If you previously installed to /usr/local, however, be aware that the packaged version installs to /opt/local and adjust any paths accordingly. The Beta-1 Windows installer has also been fixed; download it here.

9 of 53 comments (clear)

  1. Re:Usability? by bay43270 · · Score: 4, Informative

    It's in it's first beta. 1.0 is due at the end of June. Here's the story. And the roadmap

  2. Re:DeDRMS by byolinux · · Score: 3, Informative

    Miguel has tried it albeit on GNU/Linux.

    --
    Join the Free Software Foundation
  3. Is .Net on OS X a Good Thing? by mr_tap · · Score: 5, Interesting

    I am sure that others have expressed this view before, but is this necessarily going to be A Good Thing? Isn't this going to lead to developers less likely to have special OS X ports that take advantage of specific OS X features?

    Don't mean to be a whiner of course :)

    1. Re:Is .Net on OS X a Good Thing? by bay43270 · · Score: 3, Insightful

      I am sure that others have expressed this view before, but is this necessarily going to be A Good Thing? Isn't this going to lead to developers less likely to have special OS X ports that take advantage of specific OS X features?

      I think this is a great thing for OSX. OSX support will lead to full featured mono cocoa bindings. This will allow mono and .net developers to port the core logic of thier applications to the mac and still take advantage of OSX facilities for the UI and IO.

      Sure, there will always be the lazy programmers who just use mono's winforms implementation to move a windows app to the mac (like all those ugly X11 apps being moved to the mac today). In .net, those winforms implementations can be treated as a stop-gap until a new UI can be written for the app in cocoa#.

      I think mono is going to draw out a lot of windows programmers who always wanted to write for the mac or linux, but never wanted to learn the languages (Objective-C or C). Now they can keep working in C#, VB, or whatever. They just pickup a new API (cocoa# or gtk#) and start coding 'native' mac or linux apps.

    2. Re:Is .Net on OS X a Good Thing? by JimRay · · Score: 3, Insightful

      I've wondered this myself, especially given the "embrace and extend" mentality of Microsoft's past, but ultimatley I'm convinced that Mono on OS X is a good thing for the same reason Perl or Apache on OS X is a good thing. Like it or not, .Net seems not to suck. Like it or not, there seems to be a burgeoning open source community embracing .Net.

      For instance, I'm an Actionscript developer. A project I've taken great interest in is ASDocGen, which aims to bring JavaDoc-like functionality to Actionscript. This project is written in C# with the express purpose of being multi-platform via Mono.

      In the end, it makes OS X a richer platform to develop on. Rather than be limited to a few tools to do my job as a web developer, I have a vast array of options, from open source web servers to GUI text editors to Photoshop -- I can even open Word docs that clients send me without a problem. Having another tool in my aresenal only makes me a better developer.

      Apple has a very strong, committed developer base. They will continue to push great products for OS X. The ability to run some .Net apps will only make OS X better.

      --
      My other computer is your Windows box
  4. Re:Explanation of /opt/local and /usr/local by frankie · · Score: 4, Informative
    /usr/local is a commonly used place in many unixish OSes, but Apple likes to think different. This means that whenever you install a Mac upgrade (or even certain updates) there is a possibility that any non-Apple additions to /usr (also /dev, /bin, /var, /etc) will be overwritten by Apple.

    Therefore, the safe-but-annoying choice is to put your 3rd party stuff somewhere else. For example, Fink defaults to the (previously nonexistent) /sw directory. Likewise, /opt does not exist in OSX (unless you install this Mono package)

  5. Re:Aha! by Alrescha · · Score: 3, Insightful

    "Godamnit, I'd just started to get over those fink morons and their /sw tree, now we gotta put up with an /opt."

    Where do you think it should go?

    It is a long-standing philisophy in some software development circles that you never install your software into system directories (/bin, /usr). If you're adding something yourself it goes into /usr/local. /opt was used for other software providers stuff.

    I think /opt and /sw are much better than installing into system-provided directories (which is an insane practice).

    A.

    --
    ...bringing you cynical quips since 1998
  6. Finally. . .iFolder by Aiua · · Score: 4, Interesting

    I am excited about this quiet release. First, it opens up the possibility of compiling Novell's OSS iFolder on Mac OS X. Second, 60% of the computers in my company run Mac OS X, allowing for greater compatability between the remaining 40%. Third (and relating to the first), there was a recent evaluation of deploying iFolder company-wide, and the missing Mac OS X support was a critical issue. Now, the chances of the deployment happening have increased with the relase of Mono for Mac OS X. This should be great news for Apple fans.

  7. mod_mono compile fix by chasingporsches · · Score: 3, Informative

    for any of you that have tried to compile mod_mono 0.9 with the apple GCC and apache 1.3 stock installs, you may notice that it fails on "sudo make install" because it compiles it to a dylib instead of a so. here's a workaround: cd mod_mono-0.9/src; apxs -c -o libmod_mono.so -DAPACHE13 -I../include/ -I/usr/include/httpd/ mod_mono.c; apxs -i -a -n mono libmod_mono.so