Skip to main content

kmpkg in MSBuild projects

Integration methods​

User-wide integration​

To use kmpkg in your MSBuild projects run the following command:

kmpkg integrate install

You only need to run the kmpkg integrate install command the first time you want to enable MSBuild integration. This enables MSBuild integration for all your existing and future projects.

If you have multiple instances of kmpkg, you can use the kmpkg integrate install command to update which kmpkg instance is used within MSBuild. Use kmpkg integrate remove to remove MSBuild user-wide integration.

This integration method automatically adds kmpkg-installed packages to the following project properties: Include Directories, Link Directories, and Link Libraries. Additionally, this creates a post-build action that ensures that any required DLLs are copied into the build output folder. This works for all solutions and projects using Visual Studio 2015 or newer.

This is all you need to do for the vast majority of libraries. However, some libraries perform conflicting behaviors, such as redefining main(). Since you need to choose per-project which of these conflicting options you want, you must manually add those libraries to your linker inputs.

Here are some examples where manual linking is necessary (not an exhaustive list):

  • Gtest provides gtest, gmock, gtest_main, and gmock_main
  • SDL2 provides SDL2main
  • SFML provides sfml-main
  • Boost.Test provides boost_test_exec_monitor

To get a full list for all your installed packages, run kmpkg owns manual-link.

Import .props and .targets​

kmpkg can also be integrated into MSBuild projects by explicitly importing the scripts/buildsystems/kmpkg.props and scripts/buildsystems/kmpkg.targets files into each .vcxproj. By using relative paths, this enables kmpkg to be consumed by a submodule and automatically acquired by users when they run git clone.

The easiest way to add these to every project in your solution is to create Directory.Build.props and Directory.Build.targets files at the root of your repository.

The following examples assume they are at the root of your repository with a submodule of kumose/kmpkg at kmpkg.

Example Directory.Build.props​

<Project>
 <Import Project="$(MSBuildThisFileDirectory)kmpkg\scripts\buildsystems\msbuild\kmpkg.props" />
</Project>

Example Directory.Build.targets​

<Project>
 <Import Project="$(MSBuildThisFileDirectory)kmpkg\scripts\buildsystems\msbuild\kmpkg.targets" />
</Project>

Example Directory.Build.props​

<Project>
  <PropertyGroup>
    <KmpkgRoot>C:\dev\kmpkg\</KmpkgRoot>
    <MyProp Condition="'$(Platform)' == 'x64'">X64_VALUE</MyProp>
    <MyProp Condition="'$(Platform)' == 'x86'">X86_VALUE</MyProp>
  </PropertyGroup>
 <Import Project="$(KmpkgRoot)scripts\buildsystems\msbuild\kmpkg.props" />
</Project>

Example Directory.Build.targets​

<Project>
  <Import Project="$(KmpkgRoot)scripts\buildsystems\msbuild\kmpkg.targets" />
  <Target Name="_SetKmpkgEnvVars" BeforeTargets="KmpkgTripletSelection">
    <Message Text="Setting MY_PROP to $(MyProp)" />
    <SetEnv Name="MY_PROP" Value="$(MyProp)" Prefix="false" />
  </Target>
</Project>

Example triplet x64-windows-custom.cmake​

set(KMPKG_TARGET_ARCHITECTURE x64)
set(KMPKG_CRT_LINKAGE dynamic)
set(KMPKG_LIBRARY_LINKAGE dynamic)

# Pass the environment variable to port builds
set(KMPKG_ENV_PASSTHROUGH_UNTRACKED MY_PROP)

Example portfile.cmake​

set(KMPKG_POLICY_EMPTY_PACKAGE enabled)

MESSAGE(STATUS "MY_PROP is $ENV{MY_PROP}")

Linked NuGet package​

info

This approach is not recommended for new projects, since it makes them difficult to share with others. For a portable, self-contained NuGet package, see the export command.

VS projects can also be integrated through a NuGet package. This will modify the project file, so we do not recommend this approach for open source projects.

PS D:\src\kmpkg> .\kmpkg integrate project
Created nupkg: D:\src\kmpkg\scripts\buildsystems\kmpkg.D.src.kmpkg.1.0.0.nupkg

With a project open, go to Tools->NuGet Package Manager->Package Manager Console and paste:
    Install-Package kmpkg.D.src.kmpkg -Source "D:/src/kmpkg/scripts/buildsystems"
info

The generated NuGet package does not contain the actual libraries. It instead acts like a shortcut (or symlink) to the kmpkg install and will "automatically" update with any changes (install/remove) to the libraries. You do not need to regenerate or update the NuGet package.

Common Configuration​

KmpkgEnabled (Use Kmpkg)​

This can be set to "false" to explicitly disable kmpkg integration for the project

KmpkgConfiguration (Kmpkg Configuration)​

If your configuration names are too complex for kmpkg to guess correctly, you can assign this property to Release or Debug to explicitly tell kmpkg what variant of libraries you want to consume.

KmpkgEnableManifest (Use Kmpkg Manifest)​

This property must be set to true in order to consume from a local kmpkg.json file. If set to false, any local kmpkg.json files will be ignored.

This currently defaults to false, but will default to true in the future.

KmpkgTriplet (Triplet)​

This property controls the triplet to consume libraries from, such as x64-windows-static or arm64-windows.

If this is not explicitly set, kmpkg will deduce the correct triplet based on your Visual Studio settings. kmpkg will only deduce triplets that use dynamic library linkage and dynamic CRT linkage; if you want static dependencies or to use the static CRT (/MT), you will need to set the triplet manually.

You can see the automatically deduced triplet by setting your MSBuild verbosity to Normal or higher:

Shortcut: Ctrl+Q "build and run"

Tools -> Options -> Projects and Solutions -> Build and Run -> MSBuild project build output verbosity

See also Triplets

KmpkgHostTriplet (Host Triplet)​

This can be set to a custom triplet to use for resolving host dependencies.

If unset, this will default to the "native" triplet (x64-windows).

See also Host dependencies.

KmpkgInstalledDir (Installed Directory)​

This property defines the location kmpkg will install and consume libraries from.

In manifest mode, this defaults to $(KmpkgManifestRoot)\kmpkg_installed\$(KmpkgTriplet)\. In classic mode, this defaults to $(KmpkgRoot)\installed\.

KmpkgApplocalDeps (App-locally deploy DLLs)​

This property enables or disables detection and copying of dependent DLLs from the kmpkg installed tree to the project output directory.

KmpkgXUseBuiltInApplocalDeps (Use built-in app-local deployment)​

This property, when enabled, uses kmpkg's experimental built-in app-local DLL deployment implementation when app-locally deploying DLLs. This property will be removed and have no effect when the built-in implementation is no longer experimental.

This property has no effect when $(KmpkgApplocalDeps) is false.

Manifest mode configuration​

To use manifests kmpkg.json with MSBuild, first you need to use one of the integration methods above. Then, add a kmpkg.json above your project file (such as in the root of your source repository) and set the property KmpkgEnableManifest to true. You can set this property via the IDE in Project Properties > Kmpkg > Use Kmpkg Manifest. You may need to reload the IDE to see the kmpkg Property Page.

kmpkg will run during your project's build and install any listed dependencies to kmpkg_installed/$(KmpkgTriplet)/ adjacent to the kmpkg.json file; these libraries will then automatically be included in and linked to your MSBuild projects.

Known issues​

  • Visual Studio 2015 does not correctly track edits to the kmpkg.json and kmpkg-configuration.json files, and will not respond to changes unless a .cpp is edited.

KmpkgAdditionalInstallOptions (Additional Options)​

When using a manifest, this option specifies additional command line flags to pass to the underlying kmpkg tool invocation. This can be used to access features that have not yet been exposed through another option.

KmpkgManifestInstall (Install Kmpkg Dependencies)​

This property can be set to false to disable automatic dependency restoration during project build. Dependencies must be manually restored via the kmpkg command line separately.