views:

170

answers:

5

Is there some way to externalize the paths of libraries that are used in the compilation process on Visual Studio 2008? Like, *.properties files?

My goal is to define "variables" referencing locations to headers files and libraries, like *.properties files are used in the Ant build system for Java.

+1  A: 

If you're referring to influencing the location of #includes, Project properties|Configuration Properties|C/C++/Additional Include Directories is the ticket. There is also project properties|Common Properties|Additional reference search paths.

If your question is how do I parameterize stuff in a VCProj file like I would in Ant, the answer is that in VS2010 VC projects are[/can?] be MSBuild-based whereas VS2008 vcproj files are a proprietary XML based format [but as the other answers say, they have an analogous properties capability].

In the absence of more info, I'm pretty sure the standard approach for what you're doing is to add your search paths a la the first or second paragraph.

Ruben Bartelink
+1  A: 

I don't know how Ant works, but for your static libraries and headers you can edit the .vcproj file. These are XML files in fact. Libraries go in the VCLinkerTool tool tag, in AdditionalDependencies

<Tool
    Name="VCLinkerTool"
    AdditionalOptions=" /subsystem:windowsce,5.01"
    AdditionalDependencies="iphlpapi.lib commctrl.lib coredll.lib"
/>

Additional header paths are defined in the VCCLCompilerTool tool tag, in AdditionalIncludeDirectories

<Tool
    Name="VCCLCompilerTool"
    Optimization="0"
    AdditionalIncludeDirectories="dev\mydir"
    PreprocessorDefinitions="WIN32;_DEBUG;_CONSOLE"
/>

Be careful, there is one such section for each build configuration. Is this what you are looking for?

Edit : the .vsprops suggested by MSalters are more powerful; you can define additional dependencies and libraries in them an make your projects inherit these properties. Well I learned something useful today!

Stéphane
+3  A: 

I think you're looking for .vsprops files. They're comparable to the *.properties files.

MSalters
+2  A: 

Environment Variables?

All the $(xyz) replacements allowed in the propertier are, and you are allowed to "bring your own".

They are normally inherited from the parent process, so you can set them

  • for the machine / user in the system settings (usually inherited via explorer)
  • in a batch file that sets them before running devenv.exe
  • in an addin like SolutionBuildEnvironment to read them from a project file
peterchen
A: 

You can use a build system like CMake. You give CMake a high-level description of your project, and it spits out the necessary files to get your project to build correctly via another tool (e.g. Visual Studio's IDE, or a Unix-style makefile).

Paths: You can use CMake's INCLUDE_DIRECTORIES() and LINK_DIRECTORIES() commands in the CMakeList.txt configuration file to specify these paths. CMake has variables which describe both aspects of your environment (many of which can be autodiscovered, e.g. CMAKE_C_COMPILER which is the command to run your C compiler) plus any options you wish to allow the user to specify directly. All variables are stored in a separate plain text configuration file, CMakeCache.txt, that can be edited in a text editor or using a special GUI configuration tool.

CMake has many other features, like the ability to autodiscover the locations of many useful libraries, and to produce customised source/header files from "template" files containing CMake directives using the CONFIGURE_FILE() command.

Advantages:

  • Highly portable across common environments (e.g. it can produce solution files for several versions of MS Visual C++, as well as makefiles for Unix (e.g. Linux) systems).
  • Used by several large multiplatform projects (e.g. KDE)
  • Very simple to set up simple projects
  • I've found the dependency checking system to be rock-solid -- e.g. it knows to rebuild if you change compiler options (unlike naive use of make for example)

Disadvantages:

  • Ugly, primitive syntax
  • Documentation quality varies (e.g. it's sometimes hard to tell exactly what properties affect any given object)
  • Some time investment involved
j_random_hacker