All the individual executables are marked EXCLUDE_FROM_ALL, but the
added Tools custom target is marked ALL. The only visible effect of this
is that ConvertColorCursors does not get built by default, since all the
other tools are dependencies for the Resources or Tools targets, which
are both built by default. Otherwise, the benefit is simply to keep the
dependency tree clean. Only three targets are built by default:
Aerofoil, its resources and the conversion tools. Everything else is
built to satisfy dependencies.
- Includes WindowsUnicodeToolShim.h.
- Replaces sprintf_s() with std::ostringstream.
- Replaces fopen_s() with fopen_utf8().
- Switches to the toolMain() wrapper, which is a no-op on except on
Windows, where it should improve Unicode support, though I can't test
that on my end.
- Replaces \ with / in paths, which should still be Windows-compatible.
Removes unused Windows-specific headers and adds arguments to specify
source and output directories, which is necessary for out-of-tree
builds, which are necessary to avoid name collisions on platforms where
executables have no file extension (so, basically everything except
Windows).
Also add stddef.h include to GpRenderedGlyphMetrics.h to make size_t
visible. Does MSVC provide size_t by default, or via stdint.h? This
prevents compilation and I can't see how this would have compiled on
Windows otherwise.
- Adds missing includes, removes some unused ones.
- Removes unused Windows.h and shellapi.h includes.
- Uses / as path separator. This is portable and should still work fine
on Windows.
Downgrades c++11-narrowing to a warning when compiling with Clang. A
better solution would be to fix the error, but this at least brings
Clang in line with the more permissive GCC, which treats this as a
warning by default.
The BUILD_INTERFACE generator expression isn't actually useful as we
don't use export(). CMAKE_CURRENT_SOURCE_DIR is also unnecessary as
CMake treats relative paths as relative to the current source directory
(or the current binary directory for outputs).
AppendFmt calls vsnprintf twice, first to check the size of the
formatted string, then to write it for real, but it used the same
va_list for both calls, so the second call got an invalid va_list after
the first call had already consumed all its arguments.
This is UB and at least on Linux makes the second call print garbage. I
presume Windows implements va_list differently such that this somehow
worked correctly, because on Linux, all of the dialog items get parsed
into invalid JSON due to this bug, with lines like this (note the
missing second array element and closing bracket):
"pos" : [ -55947262,
This commit contains only the result of `git add --renormalize .`
`git show --ignore-space-change` can verify that this commit only
changes whitespace.
The line endings of text files in this repo are not consistent and some
files even have mixed line endings, presumably from being edited with an
editor that neither respects a file's existing EOL format nor converts
existing line endings on save.
This commit adds a .gitattributes file to mark most text files as text
in Git, which will cause Git to normalize the line endings in these
files to LF internally and to the format specified by the core.eol
setting for files in the working tree.
This commit only adds .gitattributes and does not change line endings.
The following commit normalizes all line endings for files given the
`text` attribute by this commit.
Fixes build failure on OS X 10.10 and 10.11:
error: use of undeclared identifier 'free'
error: use of undeclared identifier 'malloc'
error: use of undeclared identifier 'qsort'
