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

[Guido Draheim]

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.

That however points out a mistake in my attemps - it should not call for
"sun" as a default vendor vor any of the java lookalike targets. Still we
need to have some "canonic" name that software type, simply that it can
be used to autoconf'igure addon software.

> > Since ilvm64 may be run on a 32bit system, we do set the two
> > cpu/vm types of "ilvm" and "ilvm32" for the dotnet binaries
> > and libraries. Alongside we use "jvm" for jar binaries
>
>
> A virtual machine capable of executing programs written in java 
> programing language usually executes only classes stored in class files. 
> Some virtual machines also have the capability of executing programs 
> stored in zip archives, or jar archives. So 'jvm' is a misleading term 
> here.

The "jvm" is in the place of the "processor", the packaging format
would be indicated in the last part around the OS-KERNEL type. That's
established use for other OS/EXE variants as well. My previous mail
was trying to indicate that strongly and differentiate between an
executable segment (jvm) and packaging exe format (jar) that can be
started by an interpreter (java). Sorry if it was not _that_ clear.

> > Therefore, for jvm we do usually paste 'java' as interpreter and
> > 'jdk' as basic service series. Likewise the dotnet binaries are
> > given as 'ilrun' for the interpreter and 'mono' for the service
> > series (or something alike).
>
>
> Not all java interpreters are called 'java'. there is gij, sablevm, 
> kaffe, wonka, and a ton of others, that don't necessarily fit into this 
> naming scheme. While some of them provide java-named wrapper scripts, 
> I'm not sure if all of them do.

Correct. There may be no `java` (lowercased) wrapper script. However,
I expect that an autoconf script will detect a shellvar $JAVA to point
to it with the help of an ac_check_tool test. That test may include
other java wrapper names as tools to test for - probably testing for
a `java` wrapper first. That's why the canonic name is `java`, note
that the config.sub canonic name is always lowercase, unlike the
common form of a shellvar to point to a wrapper script.

> > jvm-sun-java-jdk
> > jvm-sun-java-j2me
> > jvm-sun-java-j2se
> > jvm-sun-java-j2ee
>
>
> uh, what's that sun doing there? ;) what's the difference between 
> jvm-sun-java-jdk and jvm-sun-java-j2se supposed to be? and so on ...
>
> I believe it would be better if you got in touch with kaffe, gcj, 
> sablevm, classpath, debian-java etc. developers before you try to push 
> something as big as this through as some kind of a GNU convention. I 
> don't know much about .net yet, and being a kaffe developer, I'm more 
> focussed on the java side of things. AFAIK, similar definitions have 
> been tried before on debian-java, and failed.
>
> On the other hand, if the virtual machine implementors of varios GNU 
> projects have already been consulted, and this is the concensual 
> proposal, I'd like to have the reference to the mailing list threads ;) 
> If that's not happended, then let's discuss this first, as it's a good 
> idea, but it needs to be discussed in a broader, more realted audience, 
> than the libtool mailing list, which, sincerely, doesn't seem like a 
> good pick to debate the finer details of naming vm systems. ;)

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.

Note that dotgnu has a compiler that can output an ilrun binary with a
jvm executable segment. They call the target -mjvm. The gcc has references
to java as well, lot's of them really. Surely one can have F/U/D about the
usage of java/jvm trademark stuff but I expect them invalid in this context
where we speak about a "canonic" name for a family of platforms, not any
product specifically. Creating a java compatible product however would need
to care about the trademark stuff, but here we do not have this case.

I'll update that patch and to erase the reference to 'sun' which is simply
incorrect. It may even give the wrong result associating the vendor to a
sub-platform that is not tied to this vendor. Thanks a lot for having a look
into the matter, Dalibor. :-)

more comments?
-- guido                                  http://google.de/search?q=guidod
GCS/E/S/P C++/++++$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode)