[Mono-dev] Cross-platform command-lines

Rafael Teixeira monoman at gmail.com
Thu Aug 9 10:39:17 EDT 2007

Hi Charlie,


On 8/7/07, Charlie Poole <charlie at nunit.com> wrote:
> Some follow-up questions, now that I've looked at mono.getOptions.
> 1) I like the idea of having the system provide this capablility,
> rather than including it in every app. But what do people generally
> do for cross-platform stuff?
>   * package it with the app for windows only?
>   * package it with the app but ignore it at runtime on windows?
>   * package it and use the local copy on all platforms?
>   * build the source right into the app?
>   * something else?

My experience on web apps, is to bundle all the binaries for the
solution, as hosting providers don't let you install things in the
GAC, as they hosts tenths to thousands of sites per server.

On the Desktop, I've seen both approaches, depending on how well
packaged/versioned the libraries are, put although the space cost,
it's better to pack your binary dependencies with the program,
especially for Windows, until some more universal dependency-resolving
system, like LLuis is proposing can be relied to solve it.

What I still find to be a hard task before us, is how such resolver,
could gather enough information to be able to optimize versions. It is
somewhat simple to use a library comparer like we use to maintain our
status pages, to look for API-breaking changes, but without 100%
coverage unit-test suites to assess semantical equivalence, one can't
be confident that an upgrade is safe, also this is also a bit too
restricting, as it looks at the whole API/behaviour spaces, it would
be nicer to have subsets of interest, so that my app could say that it
needs nunit basic testing features, but doesn't care about changes in
the conditional-testing features. Obvously this is something to be
assessed in each release of a package/app and kept in the
dependency-resolver web-hosted database (or even in the distributed
semantical web). but I digressed a lot.

Back to your topics.

> 2) Has anyone tried creating a source-file based "light" version
> of getOptions? One that could be used until a small app grew
> to the point where it needed the whole thing? If not, I might
> look at it.

Well, never heard of it, and with mono Linker, you can do it directly
in your binaries instead of having to dwell into Mono.GetOptions code.
Nevertheless, you can do that, as the license for Mono libraries,
including Mono.GetOptions permits you to that mostly anything with it.

> 3) NUnit is already using a similar, attribute-based approach
> to options. The main drawback I see is with regard to localization.
> Has anyone dealt with that issue?

Well I never had the opportunity to address that, as Miguel asked for
Mono.GetOptions API to be frozen, just when I was thinking of ways to
do so. You can look in the archives, to see Miguel's motives.

Basically the idea, would be to add another of the internal options
that would you to extract either a gettext compatible  base file, or a
strings resource file, and use the appropriate mechanism to translate
the descriptions (translating the options themselves, would make the
scripts using the app not being shareable worldwide, what I don't
think is a good thing)

I've transfered the development of new GetOptions features to
Commons.GetOptions (see
part of my managed Commons initiative) but I must confess that I
hadn't have alloted any time beyond the initial renaming/refactoring
of the code, and never published it in any repository (I intended to
do so as part of one of my projects at sourceforge, but I'm not sure
anymore that it would be best place). See now I've chosen the
Burroughs phrase to put in my signature below.

Anyway, if you are interested, I can restart working on
Commons.GetOptions, and package it in its own release and versioning

Hope it helps,

Rafael "Monoman" Teixeira
"I myself am made entirely of flaws, stitched together with good intentions."
Augusten Burroughs

More information about the Mono-devel-list mailing list