I want to use my .proj file for both msbuild and xbuild.
Currently I have paths like
$(ProjectDir)\..\..\
How can I re-write these paths so I can call xbuild on the proj file
without having to modify?
xbuild is smart enough to handle the directory separators for you, so please stick to MSBuild style. You just need to pay attention to others.
Grab a Linux box and try it out.
Related
I am creating a cmake package config file (a Foo-config.cmake) for a pre-existing .dll not created by cmake.
The annoying thing is that the .dll depends on some data files.
When a user consumes my package in his own cmake project, I want the INSTALL target to install both the .dll and data files to his specified install location. I don't want him to have to write extra install() rules to do that.
Is it good practice to write the install() rules directly in my Foo-config.cmake? Or is there a better way to do this, maybe with set_target_properties()? I just couldn't find the appropriate property for associating arbitrary file dependencies to a target.
In an alternate universe where this .dll didn't already exist and I had to create it myself using cmake, would I need to create a custom Foo-config.cmake, or is there something in cmake that can automatically generate it for me to achieve the same thing?
FWIW the .dll is an internal legacy library and is normally built by Visual Studio and uploaded in a .zip file to our internal artifactory. I want us to migrate away from manually pulling down .zip files from artifactory and manually integrating the files into Visual Studio projects.
I've since found that there are a couple different ways to do this:
In the config file, simply create one or more variables for the files/dirs you want to install. Then install those using install(FILES) and/or install(DIRECTORY). More info: https://stackoverflow.com/a/46361538/189341
Use file(GET_RUNTIME_DEPENDENCIES). More info:
https://discourse.cmake.org/t/installing-a-pre-built-module-and-its-various-dependencies/5227
How to use cmake file( GET_RUNTIME_DEPENDENCIES in an install statement?
Is it good practice to write the install() rules directly in my Foo-config.cmake?
No.
From 480 *-config.cmake and *Config.cmake files on my system none calls install().
Or is there a better way to do this, maybe with set_target_properties()?
No.
In an alternate universe where this .dll didn't already exist and I had to create it myself using cmake, would I need to create a custom Foo-config.cmake
No. This is unrelated to if you create a .dll or not. If .dll exists, there is no need to create Foo-config.cmake anyway. It is your choice that you want to (or make users to) use find_package.
is there something in cmake that can automatically generate it for me
No.
If you don't intent to support find_package features - VERSION OPTIONAL_COMPONENTS PATHS HINTS CONFIGS etc. - then just go with include(). find_package is just include() with some extra options.
If you want to have install() in your find_package, then just protect it with a variable, like if (FOO_DO_INSTALL) install(....) endif().
My company uses CMake to manage their code. Some of my colleagues are on Linux, and I'm on Windows, using Visual Studio. Our code is organised into a number of libraries, which translates into a number of Visual Studio projects under one solution.
To speed up compilation, I'm trying to integrate clcache with my setup. To do this, I need to disable TrackFileAccess for every project in the solution as noted here.
So, to my understanding, I have to modify the CMake files to either either inject some XML into each library's .vcproj file, or to modify the parameters passed to msbuild.exe itself. I'm having a lot of trouble figuring out how to do either of these things.
To try invoking msbuild.exe with specific command line parameters, I found the variable CMAKE_MAKE_PROGRAM. I tried using it with SET(CMAKE_MAKE_PROGRAM "${CMAKE_MAKE_PROGRAM} /p:TrackFileAccess=false" CACHE INTERNAL ""), but I can see from Process Explorer that msbuild.exe was not getting invoked with that argument.
I couldn't work out how I'd go about injecting XML into the .vcproj files, or if it can even be done with CMake. Is there actually a way to do it? Or would I instead need to perhaps write a script to run after CMake runs, to edit its output?
While we're at it, do I really need to edit every single .vcproj file, or could I perhaps edit something that each .vcproj will inherit?
Aha!
I did more digging, and I think I'm barking up the wrong tree with CMake. It turns out, I could edit C:\Users\me\AppData\Local\Microsoft\MSBuild\v4.0\Microsoft.Cpp.x64.user.props and add in
<PropertyGroup Label="Globals">
<TrackFileAccess>false</TrackFileAccess>
</PropertyGroup>
and it works!
My goal is to override the OutputPath property on all projects in a solution to be $(SolutionDir)$(Configuration)\. I would like to set this from within the VS2015 IDE.
I don't want to change the OutputPath in the .csproj or .vcxproj files (I know how to do this and it's not my intention to make a permanent change to the project files). I just need a local change for the moment to build.
I know I can accomplish this from the command line in a Developer Command Prompt by setting /p:OutputPath=$(SolutionDir)$(Configuration)\ on msbuild. Ideally, would like to be able to do this from within the IDE. Is that possible?
I was able to set OutputPath in a Developer Command Prompt and then launch VS2015, open the solution, and build:
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe"
Typical way of doing this is to import the same msbuild file in each project, and set OutputPath in that imported file. Disadvantage: project files need to be modified, it's not 'from within VS'. Advantage: has to be done once only, works on commandline as well as in VS, works for everybody, is pretty flexible and extensible. For example you could override OuputPath based on whether or not a certain file is present on the system, or a certain environment variable, or hostname, etc.
The answer you gave also works, though is also not from within VS. But the biggest drawback for me is that if you give your project to someone else they won't have an overriden output path, i.e. such modifications cannot really be put in version control. Of course if that's what you are after than it's fine.
I know that the latest book out on MSBuild says this is not possible, but I am sure I have seen a property that points to the current file.
Does anyone know a way to find the current file? (ie When the main MSBuild file imports a secondary file. What is the path to the secondary file from inside that file.)
I am trying to register my file in HKEY_LOCALMACHINE\Software\Microsoft\VisualStudio\8.0\MSBuild\SafeImports, but the path to the file is not constant on each of my coworkers computers and it is imported from several different projects so doing a hard coded relative path is not a good idea either.
If there is a way to get the current working directory that will work too (the working directory switches with each import and I think I could save it off)
There is not a reliable means to identify the "current file". When MSBuild processes a file it can import several other files, the end result is a single in memory complete representation of the file. When the targets are executing they do not know which file they were declared in.
This is why reusable build scripts must be "parameterized" to accept the location to known relative locations. For example if you have a dependency on the location where your folder for 3rd party references are located, the build script which is driving the process must declare that property for you.
MSBuild 4.0 Only
If you are using MSBuild 4.0, i.e. Visual Studio 2010/.NET 4.0, (which can target .NET 2.0/3.0/3.5) as well. Then you now have these properties which can be used for this specific purpose:
MSBuildThisFile
MSBuildThisFileDirectory
MSBuildThisFileDirectoryNoRoot
Sayed Ibrahim Hashimi
My Book: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build
In 4.0+ you can use properties like $(MSBuildThisFile) to do exactly this. See here
Here's my situation: I'm trying to understand how msbuild works by looking at the build files located in the .NET framework install path:
C:\Windows\Microsoft.NET\Framework\v3.5>dir /s/b microsoft*
Microsoft.Build.Tasks.v3.5.xml
Microsoft.Build.xsd
Microsoft.Common.targets
Microsoft.Common.Tasks
Microsoft.CSharp.targets
Microsoft.Data.Entity.targets
Microsoft.VisualBasic.targets
Microsoft.WinFx.targets
MSBuild\Microsoft.Build.Commontypes.xsd
MSBuild\Microsoft.Build.Core.xsd
I'm assuming that msbuild starts with Microsoft.Common.Targets, and then at some point in the future msbuild 'looks' at my vb project file extension (.vbproj) and loads 'Microsoft.VisualBasic.targets'.
two questions:
1) Is my interpetation correct?
2) can you explain to me, where is the code that determines that this is a .vbproj file, and loads 'Microsoft.VisualBasic.targets' accordingly? Is the code locked away in an assembly somewhere, or is it visible in the build files listed above?
It "starts" with your .vbproj file. Take a look at that file, it will <Import> the Microsoft.VisualBasic.targets, which in turn will <Import> Microsoft.Common.targets.
In 4.0, which is currently available in Beta, there is a /preprocess switch which will make this all clear.