This was originally intended as a safety measure to avoid mixing
packages built via AppVeyor vs packages built via other means, but this
just creates friction because of the need to edit the version field
before publishing the package.
Improve supply chain security by including a SBOM file with substituted values.
This will be used to construct a composite platform SBOM.
Signed-off-by: Richard Hughes <richard@hughsie.com>
In case of USE_POSTFIX, the POSTFIX is dependent
on the CMAKE_BUILD_TYPE.
Use the correct POSTFIX also in the generated pugixml.pc file.
This results in the following contents of pugixml.pc:
- Release:
Libs: -L${libdir} -lpugixml
- RelWithDebInfo
Libs: -L${libdir} -lpugixml_r
- MinSizeRel:
Libs: -L${libdir} -lpugixml_m
- Debug:
Libs: -L${libdir} -lpugixml_d
This keeps src/ folder clean of auxiliary files only required for
special builds; note that CMakeLists.txt already depends on scripts/
(specifically for pkgconfig setup).
Note: this chang also updates PUGIXML_VERSION macro to allow for
double-digit minor versions; this preserves the continuity of versions
so PUGIXML_VERSION >= 190 will still work.
Create visual studio projects that are vs2019 compliant.
* nuget_build.ps1 :
Introduce a new argument that will define how we implement the nuget
build. For now we accept 201{9,7.5.3} as possible argument values.
* pugixml_vs2019{,_static}.vcxproj :
Add two visual studio projects that build pugi with the latest SDK and
build tools
* appveyor.yml
- Add Visual Studio 2019 to build targets
- Add Visual Studio 201{9,3,5} to build_scripts. And call
nuget_build.ps1 with a new argument.
- Add Visual Studio 2019 to the test_scripts.
This change removes contrib folder since it doesn't seem very useful;
Natvis scripts can and should go to scripts/ along with project files.
foreach.hpp is supporting a severely outdated BOOST_FOREACH construct;
in C++11 ranged for loop can be used with xml_node::children/attributes,
and BOOST_FOREACH can work with these as well.
foreach.hpp was also accidentally licensed as public domain which isn't
very helpful when the actual library is MIT. We could fix the license
but it seems better to just remove it.
Fixes#264.
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).
