Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
OS X Businesses Operating Systems Programming Ximian Apple IT Technology

Mono Adds Mac OS X Package 53

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.
This discussion has been archived. No new comments can be posted.

Mono Adds Mac OS X Package

Comments Filter:
  • This will be very useful. I was actually going to install Mono tonight, and now it'll be a whole lot easier..

    Now all we need is Cocoa#

    Thanks Ximian!
    • Now all we need is Cocoa#

      Writing a Cocoa interface isn't hard to do; all it takes is a volunteer.

      But do you actually believe you would be programming in Cocoa using Mono?
      • I don't really know. I'm just having this wonderful period where I can finally dump Visual Basic and play with nicer things.

        I was so happy when my CurrencyConverter.app compiled.

        Day job is becoming C# and if I can write all my stuff in Something# then it'd be quite nice.
        • Well, Gtk# works well on Windows and Linux and will be available on Macintosh soon (if it's not already included in the beta, I haven't checked yet). Macintosh currently has Gtk/X11, but if Apple keeps being a viable platform at all, you are going to see a Quartz version of Gtk.
    • I'm fascinated with these different packaging types. One single "distro" of OSX, and each package seems to have multiple packages... where the opposite seems to happen with Linux. Just one package type for each of many distros.

      We can't make it easy on ourselves, can we :D

      Still, it's a concern. along with fink packages, independent packages installed in /opt, OSX style packages like gimp2 being put in /Applications (where the OS is built to handle them)... any others coming to light, to make things more co
      • by torpor ( 458 )
        I *HATE* it that they have forced an '/opt' usage in OSX.

        THERE IS -NO- /opt IN OSX! FOR A REASON!!

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

        "ln -s ~/opt /opt" ... there, that oughta fix those dufus's...

        • Re:Aha! (Score:4, Insightful)

          by Alrescha ( 50745 ) on Wednesday May 12, 2004 @10:28AM (#9126959)
          "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.
          • How about putting it into /usr/local/ as *BSDs do?

            Read hier(1) [freebsd.org].

          • Comment removed based on user account deletion
          • It should go where the OS X file structure guidelines dictates it should go, or don't bother making an OS X package.
          • by torpor ( 458 )
            Where do you think it should go?

            Let the USER decide. If you can't build a package that understands its own paths, and is re-locatable to any location, then its -not- finished, and you shouldn't release it.

            Fixed-path installs are brain-dead and only come about as the result of laziness, utter. The user has a ~/Library, a ~/Applications - both of these directories exist, are useful, and will survive backups made by your average user of their home directory. /opt is -not- something that someone is going t
            • Re:Aha! (Score:3, Interesting)

              by Smurf ( 7981 )

              If you can't build a package that understands its own paths, and is re-locatable to any location, then its -not- finished, and you shouldn't release it.

              I agree that all packages should be re-locatable. Unfortunately there are lots of *excellent* Unix/Linux and (gasp) Windows applications that are path dependent. I agree that they should be fixed when porting them to OS X, but meanwhile I prefer to have them even if they are "the result of laziness".

              OSX is a Unix for Users. Use it that way!

              Yes, but p

          • It should go in /Library.

            NOT /System/Library.

            of course, if you just want it to play around with on yoru own, you can just go for ~/Library.

            I, for one, have darwinports set up to use /Library/Ports
  • by polyp2000 ( 444682 ) on Wednesday May 12, 2004 @08:18AM (#9125752) Homepage Journal
    Is Mono actually in a state where it can be deployed?
  • Any one tried compiling DeDRMS with this? Any success?
  • by mr_tap ( 693311 ) on Wednesday May 12, 2004 @08:57AM (#9126058) Homepage

    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 :)

    • by bay43270 ( 267213 ) on Wednesday May 12, 2004 @10:47AM (#9127235) Homepage
      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.
    • by JimRay ( 6620 ) <jimray AT gmail DOT com> on Wednesday May 12, 2004 @11:13AM (#9127692) Homepage
      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 [asdocgen.org], 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 [barebones.com] 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.
    • Is it better to have software with specific OS X features, or no software at all?

      If you have to write a software to suit customers on both Windows and Mac platforms, and you hate Java (which I do, for reasons of my own and I won't discuss here), mono for OS X is definitely a good thing.
  • Not trolling, but an honest question: Why should I give a tinker's cuss? Judging by the flood of comments this story has generated, I'm hardly alone in my apathy.
  • by Anonymous Coward
    Would someone who isn't feeling too cranky explain the usage of /opt/local versus /usr/local please? I would like to understand the differences in the organizational concepts. As it is now, I just have irritation at the software that installs in the location I am less "familiar" with. Thanks.
    • by frankie ( 91710 ) on Wednesday May 12, 2004 @10:11AM (#9126757) Journal
      /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)

    • Back in my slackware linux days, I always treated /opt as the location to install whole application trees, kind of like the "Program Files" directory in Windows. So if I download Mozilla, which untars into a "Mozilla-1.6" directory or something, I put it into /opt.

      Of course, if I was using slackware's 'official' package of Mozilla, it would probably put all the binaries in /usr/bin, all the libraries in /usr/lib and so on. But for downloading and trying out nightly builds or betas, I would always use /o

    • /opt is old school unix for 'optional'. /usr/local is for stuff that isn't part of the standard vendor's install. On OS X perl is in /usr/bin/ because it is provided by Apple. Apple shouldn't put things in /usr/local/, only the local SA should put stuff in /usr/local/.

      So why do installers like DarwinPorts put stuff in /opt/? So that you can wipe out /opt without breaking everything on your system. If you wipe out /usr you would be in pain, but you should be able to wipe out /opt without pain.
  • Finally. . .iFolder (Score:4, Interesting)

    by Aiua ( 688192 ) on Wednesday May 12, 2004 @10:52AM (#9127322)
    I am excited about this quiet release. First, it opens up the possibility of compiling Novell's OSS iFolder [novell.com] 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.
    • Portable.NET has been avaliable on the Mac for over a year now and even has support for SWF (the GUI library) on mac. Good to hear that Mono is also getting thereselves over to mac. Now if only the JIT would get written for it :)
  • I'm a .NET developer who owns a powerbook. Can I now develop completely on my machine and simply copy my binaries to a windows machine?
  • by javax ( 598925 )
    superb. Mono is available via DarwinPorts [opendarwin.org] for a rather long time already.
    Why should we need this so urgently? There is no package for Debian or FreeBSD either... no one with a brain would think about making packages for those!
    • Portable.NET (http://dotgnu.org) has been avaliable for a long time via DarwinPorts and a separate disk image for a long time now as well. I am surprised that slashdotters don't seem to realize this!
  • mod_mono compile fix (Score:3, Informative)

    by chasingporsches ( 659844 ) on Thursday May 13, 2004 @02:16AM (#9136636)
    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

Business is a good game -- lots of competition and minimum of rules. You keep score with money. -- Nolan Bushnell, founder of Atari

Working...