On 5/30/06, Sebastian Redl wrote:

...

These settings are not per-project in VS, at least not typically (I'm not sure whether per-project include paths are even possible). Neither do they hurt, in particular not with Boost, where all headers are in a subdirectory. On the other hand, you _have_ to add the include and library paths, or else hard-code the full path to the Boost includes in the include file names. Nobody does that.

Sebastian Redl

There are per-project include paths in VC++ - they're under the property 'Additional Include Directories' and are added using the -I option of cl.

That's the mechanism by which I add third-party library paths to VC++ projects - although not hardcoded - I define a whole load of environment variables. I'm using VC7.1 - I use Solution Build Environment add-in (http://www.workspacewhiz.com/OtherAddins.html#SolutionBuildEnvironment) to define them, but in VC8.0 there is a built in mechanism (define a property sheet using the property manger, define the environment variables in the User Macros option) that can be used for that purpose.

Why prefer per-project settings, I hear you cry? Well, for older projects that used older versions of Boost that I really don't want to upgrade! The last time I did that (1.30.0 to 1.32.0, I think), upgrading my use of the Boost.Iterator libraries was a bit of a pain.

Oh yeah - there's also per-project library path settings as well - they obviously need to be set for Boost libraries needing linking.

Stuart Dootson

I would like to address all issues here in one mail. May be this is the best: 1. Per-Project Setting are deviation from the discussed point, but I see Per-project settings essential for distributed development, since it is possible (in visual c++) to use relative paths and manage libs related to the projects with these projects. So one can create a structure: my_project_workspace | +-- thirdparty | +-- boost 1.32 | +-- xerces 2.6 | +-- xalan x.x | +-- project files and sub projects All these projects can reference relative include paths and libs regardless of visual c++ directories set. This way you can compile sources by taking them from version control and calling build.bat or whatever script without running any fine tuning at the certain system. 2. Why would I need an installer if I can also use zip file. I understand that the installer downloads pre-build libs which I select. But try to trace how many users download only one required lib instead of the entire bunch? 3. I think a setup can feature the following selection options: - ask the user to register the PATH-EnvVar, so that binary files are automatically found (NSIS supports it) - ask the user to register boost libs in Include path of VC++ (Win32, x64, PocketPC...) - ask the user to register boost libs in Lib path of VC++ (Win32, x64, PocketPC...) There is an article in MSDN how to do that. Please read: ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.VisualStudio.v80.en/dv_vcextall/html/T_Microsoft_VisualStudio_VCProjectEngine_VCPlatform.htm It relies on .NET, but I think it is now not possible to install the VC++ without .NET Environment. 4. I would select the Windows Installer Technology anyway: - Graphical Installer creation Tool is available with Visual C++ (more or less free if you have VC++) - This Technology can be repackaged by other system administrators to deploy boost-libs within the enterprise (this happens pretty often) - Merge Modules can be used to provide users with pre-defined boost distribution components. A user only needs to select the appropriate MSM-Package to be linked with the application setup. I understand that these points require a lot, but this would be a "perfect installer". With Kind Regards, Ovanes Markarian