It looks like zipfile module by default uses the permission mask 0,
which after unpacking on Unix-based systems leads to the files being
inaccessible.
We now explicitly set file mask to rw-r--r-- to match .tar.gz defaults.
Fixes#217.
- Up to now, the libdir was hardcoded to "lib" inside pugixml.pc and
the install directory of pugixml.pc was "lib/pkgconfig"
- Adds support for lib and lib64 by using CMAKE_INSTALL_LIBDIR variable
There's really never a reason to *not* want this installed. If an option
is needed to specify installing in a versioned subdirectory, this option
should be explicitly described rather than hidden in something else.
As an added bonus, this makes the CMake install code slightly *less*
complicated.
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.
