Hi,
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
file.
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?
Kornél
----- Original Message -----
From: "Andreas Nahr" <[EMAIL PROTECTED]>
To: "Ben Maurer" <[EMAIL PROTECTED]>
Cc: "Kornél Pál" <[EMAIL PROTECTED]>; "Miguel de Icaza"
<[EMAIL PROTECTED]>; <mono-devel-list@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" <[EMAIL PROTECTED]>
To: "Andreas Nahr" <[EMAIL PROTECTED]>
Cc: "Kornél Pál" <[EMAIL PROTECTED]>; "Miguel de Icaza"
<[EMAIL PROTECTED]>; <mono-devel-list@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
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
