Tom Leys
Tom Leys

Reputation: 19029

Use a "User Macro" in .vcproj RelativePath

Inside .vcproj files There is a list of all source files in your project.

How can we use a macro to specify the path to a source file? If we do this:

<File
   RelativePath="$(Lib3rdParty)\Qt\qtwinmigrate-2.5-commercial\src\qmfcapp.cpp">
</File>

The compiler cannot find the folder:

qmfcapp.cpp
c1xx : fatal error C1083: Cannot open source file: '.\$(lib3rdparty)\qt\qtwinmigrate- 2.5-commercial\src\qmfcapp.cpp': No such file or directory

As you can see, our project compiles in several source files from QT. QT lives inside a folder of external libraries, and we don't want hardcode the path from our project to that folder (we have a very large solution)

Upvotes: 2

Views: 3151

Answers (4)

bvj
bvj

Reputation: 3392

If you add an existing file from a different drive, you'll notice an absolute path is used.

At least for v8.00, macros do not seem to be expanded. I tried VC, Ant, and OS macro forms - none worked.

There's always the sysinternals' junction option, a mapped network path, or a .lib with a macro spec set into the project/global source, include, and lib paths. Even with the lib package, you should be able to step into the source.

Upvotes: 3

tlbrack
tlbrack

Reputation: 926

Try setting an environment variable for 'Lib3rdParty' to the appropriate relative path snippet.

Upvotes: 1

stijn
stijn

Reputation: 35901

..it should be mentioned that using property sheets gets rid of a lot of the clunkyness though

Upvotes: 0

iain
iain

Reputation: 10928

The normal solution is to include the 3rd party includes, libs and source in source control with your own source, so you can track changes to your 3rd party dependencies with your source.

If this is the case, you should be able to use a relative path from each project to the 3rd party source files.

However if your solution is big, and it has project complicated settings you should look at CMake, even if you are only building on windows. CMake enables you to describe your build environment with common settings specified in only one place. More complicated cases can be handled with variables and macros. Then it generates your visual studio projects, or makefiles from this description. We introduced it to support a unix port, and now I use it for windows only development too.

VS projects are really clunky to use, opening and closing dialog boxes, setting things for debug and release. Each project with its own copy of the settings, but mostly the same as all the other projects.

Upvotes: 3

Related Questions