[Visionaries] Re: dotnet platform support / gnu config.sub (long)

[Guido Draheim]

Dalibor Topic wrote:
> Guido Draheim wrote:
>
> > Dalibor Topic wrote:
> >
> > > Guido Draheim wrote:
> > >
> > > > For the java machine, the term `jvm` is used universally. I do not
> > > > remember there were any dependency on pointer lengths, it runs in
> > > > managed mode always.
> > >
> > >
> > >
> > >
> > > JVM, JDK, Java, etc. are all trade marks with associated conditions 
> > > of use. http://www.sun.com/suntrademarks/#J . Are you sure you 
> > > want/need to use them?
> >
> >
> >
> > Yes. Actually, if the target is a java'ish machine then they will have to
> > take care of any of that legalese themselves. The config.sub thing is not
> > a java'ish thing itself here. - Furthermore, the use context is obviously
> > talking about compatiblity with a certain vm type and not identity, as
> > expressed in a lot of corners and we know that config.sub simply 
> > trying to
> > get a "canonic" variant of certain arguments given. jvm, java and similar
> > names _are_ the canonic variant of anything quite like it but not
> > the product (trademark!) itself.
>
>
> AFAIK sun has quite strict rules about claiming compatibility with any 
> of their Java products. Basically, you can't do it, unless you shell out 
> big bucks for a license to their code. But I may misunderstand what you 
> want to say.

Exactly that - there is no product here. It's a different thing whether
addon software wants to be compilable for java licenced only or
even java lookalikes. The difference is often not important during
compiling (of source), it may only be interesting during advertising
of a product (the binary).

> > No, I've been trying to get a decent cc list for dotnet targets as it is
> > a platform target that can have C/C++ source code as input - IOW a target
> > that can be different than the primary target of that software. That's 
> > not
> > the same for java. - I was including java (and python) in the 
> > description in
> > an attempt to establish guidelines for (any) other VM-type target 
> > platforms.
>
>
> It's just that all those java'ish runtimes are all somehow different in 
> my experience, so trying to put some kind of 'it's all mutually 
> compatible java' cover on it doesn't really fit. A 'abstract 
> machine'-'runtime' mapping only works as long as there are only a few 
> runtimes available. In java's case, those days are long gone, and the 
> number of options is quite huge, so fitting all of them under the same 
> cap is quite complicated, if not impossible. I assume that in few years, 
> c# will have the similar problem ;)

*LOL* there are so many i*86 compatibles, and we still put them
under the same umbrella for autoconf'iguring software. You know, here
we speak about addon software that wants to configure itself to the
_specifics_ of a _platform_. It is not important how many derivatives
are there, or even lookalikes, - however for the task of getting at
the specifics, and well, we _need_ a general guideline of the platform
family in which we want to test for specifics.