Compilation Symbols

[Stefan Bodewig <bo...@apache.org>]

Hi all,

before I started to modifiy things for 4.0 and client profile the NAnt
build was setting a compilation symbol for the "family" like "NET",
"NETCF", "MONO" and one for the specific version "NET_1_1", "NET_2_0"
and so on.  Also the conditional compilation sections seem to not assume
NET_2_0 was a superset of NET_1_1.

What I have done for now is piggy-back on NET_2_0 for both cases.

I have added CLIENT_PROFILE and NET_4_0 and define them in addition to
NET_2_0 and NET as this required the least changes to the code base.
This way I didn't need to hunt down all places that say NET_2_0 and add
a "|| NET_4_0".

But I start to feel that the correct way would have been to define NETCP
as a new "family", NETCP_3_5 ans NETCP_4_0 as new versions and to also
change all conditionals that rely on NET_2_0 so they apply to the (then)
two 4.0 and NETCP_3_5 as well.

So 

#if NET_2_0

would become

#if NET_2_0 || NET_4_0 || NETCP_3_5 || NETCP_4_0

This would create more complex conditionals but at the same time be
consistent with what has been done for the existing codebase.

What do you think?

Stefan

Re: Compilation Symbols

[Stefan Bodewig <bo...@apache.org>]

On 2011-08-21, Roy Chastain wrote:

> We must have "many" conditionals. As you noted 2.0 is not a superset of
> 1.1 and 4.0 is not a superset of 2.0. Because of CAS and other issues,
> 2.0 and 4.0 may be in direct opposition.

Agreed.

> 3.0 and 3.5 are indeed supersets of 2.0, but I doubt their importance as
> conditionals.  I would only see them as important IFF (if and only if)
> we do release a 3.5 targeted framework WITH a WCF appender.  I think the
> introduction of 3.5 as a tag should wait until later IFF we discover
> there is enough demand for a 3.5 target.

> I think that I like the idea of 4_0 and 4_0_FULL.  (Allow 4_0_COMPACT to
> be represented as !4_0_FULL.  So any 4_0 specific code that is not
> compact vs. full conditioned is under 4_0 and if it is only full it is
> under 4_0_FULL and it if is compact only it is under !4_0_FULL. I fear
> that NETCP will complicate things as we move from the 1.0/1.1 compact to
> the 4.0 compact and potentially to a 3.5 compact if that is necessary in
> the future.  (Right now, the 3.5 compact COULD be considered a 2.0
> compact.  Yes, you must target 3.5 to get the choice of compact, but you
> do not have to take advantage of 3.5 specific code.)

> I would further say that any code that works in 2.0 and 4.0 has NO
> conditionals around it, but not include compatibility with 1.0/1.1 as a
> requirement for no conditional. To elaborate, the 2_0 tag becomes 2_0
> specific code.  (Code that does not work in 4.0.)  Any 2.0 code that
> does not work in 1.0/1.1 becomes !1_0

Going forward I pretty much agree with you - but then again we may not
need to think about 1.x and compact framework at all then 8-)

For the 1.2.x branch I'd prefer to stick with the current approach in
order to minimize code changes.

> Other than MONO I do not believe the family concept will serve us going
> into the future.  What I am really saying is that the base code will
> favor 2.0/4.0 of the framework and anything that differs from that
> requires a conditional.

I'm not even convinced we'll need much Mono specific code at all -
outside of appenders, maybe.  Buth then again I must admit that there
are quite a few parts of trunk that I never really looked into, so I may
be wrong.

> This idea is probably not in keeping with the original concept, but the
> framework has grown well beyond what was envisioned when the project
> started and we might need to adjust our thinking to match.

+1

Stefan

RE: Compilation Symbols

[Roy Chastain <Ro...@roychastain.org>]

We must have "many" conditionals. As you noted 2.0 is not a superset of
1.1 and 4.0 is not a superset of 2.0. Because of CAS and other issues,
2.0 and 4.0 may be in direct opposition.

3.0 and 3.5 are indeed supersets of 2.0, but I doubt their importance as
conditionals.  I would only see them as important IFF (if and only if)
we do release a 3.5 targeted framework WITH a WCF appender.  I think the
introduction of 3.5 as a tag should wait until later IFF we discover
there is enough demand for a 3.5 target.

I think that I like the idea of 4_0 and 4_0_FULL.  (Allow 4_0_COMPACT to
be represented as !4_0_FULL.  So any 4_0 specific code that is not
compact vs. full conditioned is under 4_0 and if it is only full it is
under 4_0_FULL and it if is compact only it is under !4_0_FULL. I fear
that NETCP will complicate things as we move from the 1.0/1.1 compact to
the 4.0 compact and potentially to a 3.5 compact if that is necessary in
the future.  (Right now, the 3.5 compact COULD be considered a 2.0
compact.  Yes, you must target 3.5 to get the choice of compact, but you
do not have to take advantage of 3.5 specific code.)

I would further say that any code that works in 2.0 and 4.0 has NO
conditionals around it, but not include compatibility with 1.0/1.1 as a
requirement for no conditional. To elaborate, the 2_0 tag becomes 2_0
specific code.  (Code that does not work in 4.0.)  Any 2.0 code that
does not work in 1.0/1.1 becomes !1_0

Other than MONO I do not believe the family concept will serve us going
into the future.  What I am really saying is that the base code will
favor 2.0/4.0 of the framework and anything that differs from that
requires a conditional.

This idea is probably not in keeping with the original concept, but the
framework has grown well beyond what was envisioned when the project
started and we might need to adjust our thinking to match.

----------------------------------------------------------------------
Roy Chastain