Mailing-List: contact log4net-dev-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4NET Dev" <log4net-dev@logging.apache.org>
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
From: Stefan Bodewig <bodewig@apache.org>
To: "Log4NET Dev" <log4net-dev@logging.apache.org>
Subject: Re: Changed some defines
References: <87k3goivgu.fsf@v35516.1blu.de>
	<007301ced935$08370280$18a50780$@gmail.com>
Date: Mon, 04 Nov 2013 12:43:27 +0100
In-Reply-To: <007301ced935$08370280$18a50780$@gmail.com> (Dominik Psenner's
	message of "Mon, 4 Nov 2013 09:08:06 +0100")
Message-ID: <87r4awtmsg.fsf@v35516.1blu.de>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain

On 2013-11-04, Dominik Psenner wrote:

> Having a general FRAMEWORK_X_Y define wouldn't be bad. But maybe every
> FRAMEWORK_X_Y should read as "FRAMEWORK_X_Y_OR_ABOVE" since every framework
> is compatible to its ancestors.

fine with me, I'll make the adjustments.

> Still I would keep these defines:

> * MONO := set when build for Mono
> * MONO_X_Y := set when built for Mono
> * DOTNET := set when built for the .NET framework

What you call DOTNET currently is NET, but that will be easy to change.
In addition we still have NETCF for Compact Framework.

My hope is we don't need MONO_X_Y but only MONO and the matching
FRAMEWORK_X_Y_OR_ABOVE.  We'll see once we try to target Mono 3.5 and
4.0 as well but I'd rather reduce the repetition all our different build
targets cause in the build files, first.

> building for a newer .NET framework should define all other frameworks
> since every future framework will be compatible to all ancestors. For
> example while building for .NET 4.0 the following defines should be
> set:

> {FRAMEWORK_2_0_OR_ABOVE, FRAMEWORK_3_0_OR_ABOVE, FRAMEWORK_3_5_OR_ABOVE,
> FRAMEWORK_4_0_OR_ABOVE, DOTNET}

Agreed in general, but given FRAMEWORK_2_0_OR_ABOVE is our baseline I'd
assume it implicitly for all builds (that are not NETCF).  Also
FRAMEWORK_3_0_OR_ABOVE wouldn't be used for anything and I don't expect
us to use it.  Let's introduce it once we need it.

> Despite all this, I'm not sure if we need something like
> FRAMEWORK_X_Y_ONLY.  This would need further evaluation based on the
> current codebase.

There is no such case right now.  We really only have a single place
where 3.5 is checked and it is enabled for 4.0 as well.

If we ever need it, we can simulate it with something like

#if FRAMEWORK_3_5_OR_ABOVE && !FRAMEWORK_4_0_OR_ABOVE 

Stefan