Using LTCG restricts the resulting .lib files to a specific compiler
version, causing version conflicts when the compiler gets updated
without changing the toolset version. VS2017 now has two incompatible
compilers, 15.0 and 15.3, both of which use toolset v141...
Unify build paths in all MSBuild VS projects and extract common build
logic into functions.
Note that this change changes both VS2010 and VS2013 projects to have
more predictable output paths and fixed output file name (pugixml).
We'd like to build pugixml with both static & dynamic CRT and put it
all in one NuGet package.
CoApp sort of allows us to do this via dynamic/static pivots, but it
does not let us customize the names of the pivots and additionally has
some bugs with the project setup. Their project modifications are also
much more complicated - really, at this point we should do this
ourselves.
Create a simple native NuGet package with Linkage setting that picks the
right library, and package all libraries appropriately. Note that we use
the unified path syntax to make it simple to just get the right .lib
file from the toolset/platform/configuration/linkage combo.
Correctly check for error codes and don't run .bat file since it doesn't
work anyway (the variables it sets aren't accessible in PowerShell, and
the path to the script doesn't seem to be the same in VS2017).
We used to use the current timestamp when building the archive; switch to using
the timestamp of the tag with the version we're packaging.
This requires some monkey patching since tarfile module is always using current
timestamp when writing gzip header...
Also exclude archive.py from archive and simplify release file list in Makefile.
Put debugging information into the object file so that it can be shipped
with NuGet binaries. Based on the linker settings for the executable
debug info will either be put into the final .PDB or stripped out.
Fixes#110.
Move pugixml project file for VS2015 to scripts/ and unify the output file
structure similar to old VS201x projects. Remove test projects and solution
since they are not required for building.
Provide more accurate information in the package script and handle build
errors during package construction properly.
We now make sure that in CMake builds we have long long support. This requires
CMake 3.1 for target_compile_features.
Fixes#53 (as long as packages use this CMake script... most of them do)
- Include GNUInstallDirs which sets up standard install locations including
lib64 for mulilib systems.
- Make BUILD_SHARED_LIBS an option instead of a variable which is better for
use in either the cmake-gui or ccmake gui interfaces.
- Setup a destination for WIN32 runtime DLL's which is also helpful for MinGW
installs.
git-svn-id: https://pugixml.googlecode.com/svn/trunk@1012 99668b35-9821-0410-8761-19e4c4f06640
