Reputation: 8449
The short question:
I want to be able to use the path of the props file as a macro from inside the props file (like the ability to reference the project directory as $(ProjectDir)
)
The long question
I use props files to add reference to various 3rd party libraries.
This is simple if I can specify an absolute path to the 3rd party library.
However, I want to specify a relative path - as different team members use different location for the source control tree. is there a method to add such relative paths to the props file?
specifying a path relative to the project directory isn't a good solution either, as the location of projects isn't fixed (so for one project I would need $(SolutionDir)\..\XXXX
and for another one I would need $(SolutionDir)\..\..\XXXX
Upvotes: 7
Views: 5788
Reputation: 38961
The solution is: $(MSBuildThisFileFullPath)
(or, rather $(MSBuildThisFileDirectory)
). (Which is noted in passing here.)
If this is used within a property sheet file (.props
) it will refer to this property file/dir itself. (Note: When used on the .vcxproj
level, it will refer to the project file/dir.
Tested with VS2013 RC and VS2010.
Upvotes: 21
Reputation: 51
@John Dibling: That's a bad solution for any group that works on concurrent branches; you'd have to switch your environment around all the time, or locally edit .props files on each branch. That's miserable when you're constantly switching branches.
Unfortunately I can't seem to work out a better solution. In my head it'd be something where a top-level .props defines a user macro like PROJECT_ROOT (defined as '../../'), and then other .props files inherit and use that macro. That way you can share one .props file with solutions in multiple different relative paths. Unfortunately it looks like user macros are not inherited in .props files.
There must be a real solution to this that doesn't involve locally configuring a build environment given a static directory structure across multiple branches.
EDIT:
Looks like I found a solution to this one, for real. Basically you have one relativepath.props file that defines a user macro with your relative path, another props file that uses that macro for all of it's paths, and then the file you actually import into your vcxproj will look like this, including both property sheets. That's the only way I can get it to use the macro from one file in other files.
Then different solutions in different relative paths can use different paths, while the properties are only defined once in realprops.props.
<ImportGroup Label="PropertySheets">
<Import Project="relativepath.props" />
<Import Project="realprops.props" />
</ImportGroup>
Upvotes: 5
Reputation: 101506
I would suggest that you have conflicting interests:
#include
paths#include
paths.This isn't the answer you were looking for, but I would suggest you take a different approach.
Two come to mind:
Let each developer define build-time macros in the Microsoft.Cpp.x64.user
file, such as $(MY_PROJECT_ROOT)
, and in the checked-in props file, specify directories relative to those macros.
Use an absolute path in the checked-in props file, but make that absolute path a junction point, such as X:\
. Each developer would define where X:\
points to.
Number 2 has an advantage of making it a little easier to switch between trunks. Perhaps say release 1.0 of you application an Beta 2.0 of your application. You can use the same props file in both; the developer would just run a batch file to switch junctions when moving from one trunk to another.
However Number 1 has the advantage of being a solution completely enclosed within the IDE.
Upvotes: 1