Boost logo

Boost-Build :

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-09-16 02:04:21


Andrey Melnikov wrote:
> Reece Dunn wrote:
>>/wd0000 gives the following error:
>>
>>cl : Command line warning D4014 : invalid value '0' for '/wd'; assuming
>>'4999'
>
> 0000 was just a placeholder for the real "deprecated" warning number.

Do you mean for functions declared __declspec(deprecated) or for actual
warnings that have no use?

>>>>>>[4] support for managed (CLR) and Java bytecode
> I actually didn't make a difference between MC++ and C++/CLI. I called
> them both MC++ as opposed to standard C++.

Ok. I get you.

>>Microsoft have added facilities for their .NET platform, which is
>>another bytecode (Intermediate Language) system running on the Common
>>Library Runtime (CLR). C#, VB.NET and others implicitly target the CLR
>>like Java targets the JVM.
>
> .NET platform isnt "their". There are open, free and compatible clones:
> Mono and DotGNU. There are free cross-platform C# compilers that compile
> to the same intermediate language as MS, free CLR libraries and
> JIT-compilers. It's possible to run the same managed exe on Windows and
> *nixes. The GCC-CIL I mentioned is the C++ compiler for Mono project. It
> generates Microsoft CIL too.

What I mean't by "their" was that Microsoft invented it. I was aware of
the Mono project, however I didn't know that GCC-CIL targetted Mono.
Thanks for the info.

>>So, if we have:
>>
>># builtin.jam
>>feature bytecode :
>> native # target native CPU machine code
>> java # target the JVM machine code
>> dotnet # target the .NET/CLR machine code
>> cil # other (e.g. GCC) intermediate representation
>> ;
>
> What is "cil" here?

You keep referring to GCC-*CIL* -- that's what cil was there.

> IMO there are no big difference between bytecode executed by a virtual
> machine, bytecode compiled just-in-time and executed natively and native
> code. They are all compiler outputs.

Agreed.

> So there's no need for <bytecode>. We already have "<architecture>" and
> CLI and Java are just two virtual architectures.

This makes sense.

> feature architecture :
...
> # CLR CIL
> clr
> # Java byte code
> java
> : propagated optional ;

Do we even need the clr/java bytecode separation? Could we have
<architecture>bytecode, and have .NET/Mono compilers generate CLR and
Java compilers generate Java bytecode.

> <clr>pure/safe feature IMO OK. I'm just against "bytecode". And so far
> you didn't provide any arguments in favour of a searate feature.

I was not championing the use of a <bytecode> feature, just finding the
best way to support CLR and JavaVM. You have convinced me of a better
way of representing them :).

- Reece

 


Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk