[Mono-dev] Cross-platform command-lines

[Charlie Poole]

Hi Rafael, 

> 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.

This makes sense to me and I think I'm going to go with it - at
least for NUnit on Windows, the issue came up because I
was publishing a really small helper program, which - like
all such programs - does its own  adhoc command-line processing.
 
> 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.

An interesting digression, however. For NUnit, I'm thinking about
segregating subsets of functionality by assembly - to a greater
degree than it is now - for the 3.0 version.

> 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.

Ah! I hadn't thought of that. This would be handy for small,
commandline programs that normally get copied into some bin
directory.

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

Perhaps a strategy could be injected by the derived class or
using app. The default implementation could use attribute
properties and would be available as a fallback to any
internationalization strategy.
 
> I've transfered the development of new GetOptions features to 
> Commons.GetOptions (see 
> http://monoblog.blogspot.com/2007/01/commonsgetoptions-sucessor-to.html
> 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.
 
That could be my sig, as well. :-(

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

I'm interested - either as Commons.GetOptions or doing a
(hopefully temporary) fork as NUnit.GetOptions. That way, 
NUnit itself could use it and it would be available for the
use of the series of small utilities I'm starting to publish. 

In fact, since it doesn't make any sense to install one of
my NUnit Extras if you don't already have NUnit, I can just
assume it's present for them.
 
> Hope it helps,

It did.

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