Well, I finally had another shot at getting Mono on Mac OS X to run NAnt
and do something useful… and guess what? Success!

Now, the gritty details…..

I am using the latest mono framework for Mac OS X, which is 1.1.2 from
the devleopment build. I don’t know if that’s required, but Mono is a
bit thin to begin with on Mac, so the latest doesn’t hurt too much.

Also, I’m using nAnt-0.85-rc1, which is the latest release candidate
snapshot. That’s more out of want than need, as we’re moving to 0.85 at
work, and it’s a Good Thing™ to be up to speed on the tools you make a
living off of.

So there is some hope. Haven’t got Cocoa# or Gtk# installed or built
yet, but at least with NAnt actually functioning, there is a little hope
now without days of pain and file lists (no thanks, better things to do).

Of course, there is one trick that was causing much of the pain.
pkg-config. If you use Fink, you’re probably getting the fink pkg-config
that by default is in /sw/bin. When you’re running NAnt, you want the
path of /Library/Frameworks/Mono.framework/Commands to be before that
one, as there is a pkg-config there that deals with it. I have no idea
how the two interact or relate, and I’m just going to wrap the NAnt in a
shell script that mods that path for it to run. I have a lot more useful
stuff as part of Fink that I value more than mono on a Mac.

Well, after the Nant frustration (still no luck there BTW), I dug in and
tried to do something useful anyway getting this stuff running.

NUnit works very well. The mono binaries can be used as-is, bypassing
needing a NAnt build tool to assemble it.

For some simple stuff that doesn’t need a big freaking build system like
NAnt (you know, like more than about 5 classes :^) ) this with mcs and
mono can work OK. I’ve only used the command line and developed non-GUI
classes, but it does seem to be working OK.

The next step is that Ant itself has .NET tasks. I’ll give that a shot
and see if it Moofs.

I still much prefer Java and/or Objective-C to this stuff, but it never
hurts to know a few more platforms.

Well, I’ve been mucking with .NET at work for a while now, but on the Mac
at home I’ve been Java and Objective-C for the fun stuff. I decided that
it would be interesting and useful if I could try out at least SOME of the
things at work on the Mac at home. Good theory.

The mono package for OS X 10.3 works decently well actually. mcs (the C#
compiler) seems to handle the bulk of really simple examples, and mono
(the runtime) can execute the same stuff. So far so good. Now to try the
heavier lifting.

Start with the tools. NAnt. Crap. Full stop. This thing will not compile
under Mono on Mac (Fileset # of args invalid) and the precompiled
binaries will not run on mono on the Mac (reflection exception). Haven’t
tried NUnit, but without NAnt, doing much of anything useful will be a
bit of a pain.

NAnt is a hell of a tool. But there’s certainly something odd about the
defacto open source build environment that would not compile under the
1.1 framework at all, and that won’t cleanly compile or run under an
otherwise seemingly decent version of mono. Heck I got the database
connection and ADO.NET stuff working to Postgres without any issues at
all. What code-fu is NAnt doing that makes it so ill-tempered?

Ah well. Back to Java and Objective-C goodness. I can always VPN to the
office and remote desktop to do the .NET stuff. It’s sure not worth the
effort at this point to muck with it on the Mac. It’s just not mature
enough yet for anyone except the people who want to build it. I hope
they continue, but I’ve got little enough time and too many projects on
the list to add mono. Sorry. And don’t even get me started about that
abysmally documented effort of DotGNU. Great idea. Make it a fink
package or some sort of package that works. Setting up darwinports is an
adventure in mailing list scouring. ARGH.

I got interested in an ongoing mini-debate in the java blogs. Oddly enough
between James
Gosling and John
Munsch. I posted a comment on John’s blog (sorry that mind doesn’t
support that. I’m not a big draw. Email me. dallas OVERAT hockley dot ca
)

The general thought I’ve got is essentially a development biodiversity
(comment 14 I believe). Not only can we not stop duplication of effort
on various very similar projects, but that sort of diversity and
inefficiency should actually be encouraged. 1 in 10 startups
actually succeed. Better hope we start enough to get a successful one.

The post is copied below. For the original references, follow the links.

You have a point as far as getting Open Source software to accomplish
something. Humans being what they are, you also seem to agree that
opinions and differences of opinion will result in duplication and
diversification of effort (Gnome and KDE for example). There are a
couple more aspects that are ripe for consideration in this context.
Programmers can’t just go and start writing useful code, and grok the
world of the Right Thing&trade.

Just as for those that did the compSci degree, they write hello world,
and binary tree code, and yet another pascal compiler, etc. etc.,
there is a learning process. I think that’s where Gosling is coming
from. Learning. I think the fact that “perusing Freshmeat” brings up
90 scripting language projects. Like we need another one.

502 projects around text editors. Guaranteed not all are gems or
“worthy” of the efforts of people. Let’s say that 10 deserve a place
in the “commercial-quality” level, in that they serve different user
groups, segments, tasks etc. Should anyone with a desire to code on
those pick one of the top 10 and just dive in?

I personally hope not. We didn’t all start coding on the same day, we
don’t all have the same experience or ability level. Start with a
simple, non-featured one that might be a bit hacked up. Look at the
code from the leader. Get into the concepts. Understand some of the
approaches. Try some things yourself. And don’t expect to get your
code accepted by the top project all the time. To get to the level
that your code and ideas are truly good enough for the project, you
need to evolve your skills, views, ideas and code to the level of the
project. You need to do that by learning and trying. On a duplication
of an existing project in a lot of cases. Just another level of
another “hello world” program.

If you still don’t see the point, perhaps we should have dumped all
the effort into Minix rather than Linux. What was Linus thinking when
he didn’t just evolve one of the many open source efforts of the time?
Lucky that he did go his own way, as his particular mode of work, and
base of code, and level of ability seem to have done something the
other efforts didn’t or couldn’t achieve.

Diversity and inefficiency is a very, very effective way of trying
various strategies. Not all will work. Not all the eggs are in one
basket. And gradually, through selection, merit, (marketing?) a top
contender may get extra deserved(?) attention like ALSA did. But if
you only try one way, you’re going to get whatever quality you started
with.

Vive la difference!

Posted by Dallas Hockley at March 25, 2004 09:28 PM

I had the opportunity to attend a talk by Martin Fowler.

It was less themed and more ranging than one would expect from a
highly-regarded author, and as such, I found it that much more
interesting and valuable. He covered a lot on patterns and new books
coming out, as well as some books that have shaped some of the design
and architecture aspects of the programming field. He touched on some
interesting ideas around domain models as the underlying foundation of
enterprise apps. Definitely worth more investigation.

One thing that crossed by mind that I will have to look into is whether
there are any pattern repositories that address the security that could
be applied to a pattern. I wonder if we are reinforcing the security
afterthought epidemic by basing patterns on the pure, unassailable
programs we create in our minds where the crackers can’t get at them…