| commit | 88aa5c6a77dc62c3a13782cee6459997449ee227 | |
| author | upstream svn <svn@amule.org> | |
| Fri, 20 May 2016 16:23:58 +0000 (20 16:23 +0000) | ||
| committer | Dévai Tamás <gonosztopi@amule.org> | |
| Wed, 25 May 2016 08:42:50 +0000 (25 08:42 +0000) | ||
| tree | 93f5b72127138de11c6b647ec1a127991d812bc7 | treesnapshot (tar.gz zip) |
| parent | 01db708a4e96394673b509ed2f13a3d2bdeb5061 | commitdiff |
Renewed mule version description
The old GetMuleVersion() function was flawed in several aspects: checked for
wxBase before wxMSW, and the whole thing being in OtherFunctions (which is always
compiled with wxBase) resulted in all Windows applications being described as
using wxBase.
The new approach uses a lightweight inline function, which is compiled separately
for all applications. Thus it can properly describe both GUI and command-line
applications. Despite the function body being long and sometimes cryptic, it is
as lightweight as it can be. Most of it is for the preprocessor, and the compiler
concatenating string literals. The best case is that the function returns a
constant string. In the worst case it has to create a temporary wxString object
and process two additions to it.
I don't even know if aMule can be compiled at all for the wxWidgets configurations
we check, but we're now prepared for each possible case :-)
The variable MuleBoostVersion now exists only in Boost-enabled builds, no more
need for placeholder dummies.
The old GetMuleVersion() function was flawed in several aspects: checked for
wxBase before wxMSW, and the whole thing being in OtherFunctions (which is always
compiled with wxBase) resulted in all Windows applications being described as
using wxBase.
The new approach uses a lightweight inline function, which is compiled separately
for all applications. Thus it can properly describe both GUI and command-line
applications. Despite the function body being long and sometimes cryptic, it is
as lightweight as it can be. Most of it is for the preprocessor, and the compiler
concatenating string literals. The best case is that the function returns a
constant string. In the worst case it has to create a temporary wxString object
and process two additions to it.
I don't even know if aMule can be compiled at all for the wxWidgets configurations
we check, but we're now prepared for each possible case :-)
The variable MuleBoostVersion now exists only in Boost-enabled builds, no more
need for placeholder dummies.
13 files changed: