This makes it so we no longer try to steal the console back to a log
file when using --wconsole with the new redirection code. Now the
--wconsole switch triggers a special mode of the log file manager that
uses a native console instead of log files.
As a necessary bonus to appease compilers, the GUI2 version info dialog
now uses the correct log file path when not started with the --wconsole
switch. Yay!
This replaces SDL 1.2's built-in stdout/stderr redirection, which writes
the log file to the process working directory (usually an
admin-restricted location) instead of a more accessible user-writable
location.
My approach combines stdout and stderr into a single log file which
includes the process id and timestamp in its filename in order to
accomodate multiple instances and (coming later) log rotation. The log
file is created in the user's temporary directory defined by Windows,
and then relocated to the game user data dir as soon as it is set-up the
first time, placed in the Windows-specific logs/ subdir.
The most pressing issues this solves are the lack of built-in
stdout/stderr redirection in SDL 2's SDL2main.lib entry point, and
Unicode path issues with SDL 1.2 (bug #22897). Additionally, it allows
us to not have to rely on UAC virtualization anymore; this is arguably
far more important because it has been known to break on occasion (e.g.
<http://r.wesnoth.org/t42970>), and starting with version 1.13.2 we want
to declare Windows Vista - 10 compatibility in our side-by-side manifest
(see commit e119f4071f047c6d740ebec4636985fdf39349bc).
Currently missing features coming later:
* Log rotation (otherwise the logs/ dir may grow forever)
* wesnothd support (although the code is already required to be linked
into wesnothd due to it being required by the FS API)
* Integration with the version info dialog
The previous version of the modules worked only with OS X 10.9. This
version works with both 10.10 and 10.9 (and potentially with 10.8; we
currently have no 10.8 system available for testing).
These modules do not work on OS X 10.6 and 10.7. Different methods of
building Wesnoth will be provided for those OS X versions (and
potentially for 10.8).
OS X 10.5 and earlier is no longer supported by Wesnoth 1.13 (that is
unchanged by this commit).
- All files are now ordered alphabetically.
- All referenced header files are now known to the project file.
- Duplicated references to source files and libraries are removed.
- References to defunct sources are removed.
- Source files are now largely stored in a structure mirroring the file system structure,
meaning a few new added groups and some files moved around (some of which were
in nonsensical places before).
Fixed an issue caused by 659b9a4 - the 'Start Debugging' option was
basically useless as the process terminates itself if OMP_WAIT_POLICY
isn't defined.
Cleaned up unnecessary configurations for WindowsTimeout.
Fixed duplicate manifest.
Disabled WML unit tests on MSVC Debug builds as they would quintuple build
duration (over 60s per test).
Re-enabled stdout redirection in WML_tests.cmd to avoid spamming the
command line.
Updated vcproj for daa2140 (added multimenu widget).
Highly unreliable and generally useless, see the Doxygen documentation.
Also missing the actual Windows implementation for the moment. Also,
since uname() is highly useless on most platforms, I'll need to think up
a better OS X implementation later down the road.
Registers library versions in a single structure that can be queried
later as many times as necessary (say, from the game UI) instead of
relying on recording this information in different object files in an
inconsistent fashion. Also, it provides a pretty formatter for console
usage (e.g., in --version).
libpng also gets to join in the fun.
As the vcproj format is poorly documented, we previously couldn't find an option to pass compiler/librarian/linker dependencies without manually adding them in the menu. After installing VC9, I found an option that is correctly ported to vcxproj (the new format since VC10) and allows to specify these additional dependencies.
This is only recognized by the game client at the moment. The
implementation is a bit hacky but it seems to work. Thanks, SDLmain.
The cwesnoth.cmd Windows batch file passes --wconsole to Wesnoth in the
command line, along with any other arguments passed to it. This is
intended to be *the* use case for --wconsole, since otherwise the fact
that Windows won't allocate a console for us on process initialization
(due to Wesnoth being compiled with the GUI application flag) causes
issues with the Command Prompt shell -- namely, the shell returns
before Wesnoth allocates its console, allowing shell input to happen
concurrently with Wesnoth's output to console.
cwesnoth.cmd should be used in shortcuts and given Wesnoth's install
path as its initial working directory.
