[Mono-devel-list] [PATCH] Profile 2.0 assembly versions

Kornél Pál kornelpal at hotmail.com
Thu Jul 28 18:57:02 EDT 2005


Bens idea is good. There should be a single file to define versions.

Then the assembly references could be in the Consts.cs files of each
assembly but there were no #if clauses to specify version because the
reference constants could use the version constants defined in the common

BTW is there a way to have a common .sources file because it seems that we
are going to have more and more common files that has to be added to the
.sources file of each assembly?


----- Original Message -----
From: "Andreas Nahr" <ClassDevelopment at A-SoftTech.com>
To: "Ben Maurer" <bmaurer at ximian.com>
Cc: "Kornél Pál" <kornelpal at hotmail.com>; "Miguel de Icaza"
<miguel at ximian.com>; <mono-devel-list at lists.ximian.com>
Sent: Friday, July 29, 2005 12:42 AM
Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions

> Yes - it would make a lot of sense to put them into a single file. However
> it would come at a cost of up to 2kb of size added to EACH assembly that
> uses Consts.
> In fact I think we could do something really clever to our compiler here,
> that would also benefit for a lot of other cases.
> AFAIK the compiler can already eliminate dead code. I would propose a step
> that allows the compiler to scan for dead code again AFTER constants are
> resolved. This way the compiler would be able to completely eliminate the
> Consts Class after compiling. This would also add lots of added value to
> other applications. It's quite common to use private consts and especially
> enums to structure the code and make it more readable. With the proposed
> compiler function all of these things could be thrown out at compile-time,
> which could help a lot of applications to get smaller.
> We could add a compiler-switch for that like -EliminatePrivateConstants
> Andreas
> ----- Original Message -----
> From: "Ben Maurer" <bmaurer at ximian.com>
> To: "Andreas Nahr" <ClassDevelopment at A-SoftTech.com>
> Cc: "Kornél Pál" <kornelpal at hotmail.com>; "Miguel de Icaza"
> <miguel at ximian.com>; <mono-devel-list at lists.ximian.com>
> Sent: Friday, July 29, 2005 12:11 AM
> Subject: Re: [Mono-devel-list] [PATCH] Profile 2.0 assembly versions
>> On Fri, 2005-07-29 at 00:07 +0200, Andreas Nahr wrote:
>>> No Consts.cs aren't automatically generated.
>>> The problem is, that several Attributes of classes in System.Web do not
>>> use
>>> the consts scheme, and about one third of your (BIG) patch is just for
>>> changing these Attributes.
>>> We will then have to change these again later, so it might make sense do
>>> do
>>> it now instead of doing it twice (and adding lots of changelog entries
>>> twice).
>> If we really want to be clever, and avoid doing things twice, we can put
>> this:
>> internal class MonoConsts {
>> #if ...
>> public string FXVersion = ...
>> #elif ...
>> ...
>> #endif
>> }
>> in the common build directory. This way, the next time we need to target
>> another FX, we don't have to do it in 100 places.
>> The Const.cs is probably still a good idea, since it is really ugly to
>> have those magic names lying around the source code.
>> -- Ben

More information about the Mono-devel-list mailing list