Is there a way to adjust visual-C++ (MS VS 2010 EE) project properties in such a way, that the same .sln files can be built just in one click among different computers (on Windows, of course)? - so it will be possibly to upload visual-C++ projects to SVN server. Project uses some libraries (header and .lib files) with absolute (system dependent) path (e.g. boost) and it's own utils.
You can use environment variables in your project settings by enclosing them in $(). e.g. if your environment defines BOOST_INCLUDE:
set BOOST_INCLUDE=C:\boost\include\boost-1_45
then you can use $(BOOST_INCLUDE) in your settings to refer to the Boost include directory.
Visual studio allows you to configure search directories for include files and libraries per system. You must agree with your colleages which folders should be made part of this scheme. Alternatively, you could use a set of predetermined environment variables and use paths relative to those.
Visual studio has some identifier like $(ProjectDir) that you can use in the project settings.
For example you could put a path like "$(ProjectDir)....\headers\boost\" in your include search path and it would work for multiple location of $(ProjectDir).
Other like $(ProjectName), $(ConfigurationName), $(IntDir) (Intermediate directory) can also be usefull.
I don't have a reference link for the moment.
Related
say I have a sln which contains 10 projects(named proj1 to proj10), and proj1 is the default project which generate the EXE file.
My problem is: how to place the 'include' folder?
I mean if proj2 uses proj3(that is including its header file and linking its lib file), how to place the 'include' folder?
there are two approaches:
place all header files and lib files in a different root folder which is in the same level of the project
make every project self-close, and the other projects who want to use this project should take care of the include-path and link-path. Of cause we should give a rule to the layout of every project(e.x. every project MUST have a 'include' folder and 'lib' folder in the root folder)
any suggestion?
thanks
When it comes to Visual Studio, I don't like either of the two approaches you suggested, although mine is most closely related to your Option #2. The way I like to organise it is like this:
<SolutionRoot>
<Project1>
project1.vcxproj
someheader.h
somesource.cpp
<Project2>
<Project3>
<Project4>
<Project5>
application.sln
In case that's not obvious, that's a quasi-directory listing showing some project folders and the base solution file.
All new projects are just added to the solution using Visual Studio's default settings. Trying to go against this and making projects work like Linux projects (lib, include, src etc) just ends up causing you grief, so don't do it.
Now, I set my "additional includes" path on every project to $(SolutionDir). Then if I want to include something from Project1:
#include "Project1/someheader.h"
The advantage of this is you don't clutter up your 'additional includes', so it's easy to see at a glance what external includes a project has.
As for linking to lib files, why not take advantage of Visual Studio's project references feature. Honestly, your life will be easier. Simply hook it up so that Project2 references Project1, etc... Then you don't have to worry about libraries and linker paths. You only do that for toolkits that are outside your solution tree (eg distributions such as libpng or openssl).
Again, you free up that setting so it only shows linkages outside of the solution. The other advantage is that your build order is implicitly defined if you use references.
I would go with the 1st solution. it make the project settings simple. As the C++ projects we worked on, we always put the header files together.
I am using VC++ with multiple projects that require a 3rd party library. As developers may have this library in different paths, each developer sets the local machine/user's Microsoft.Cpp.Win32.user property sheet with the appropriate paths.
Now we using a new version of the 3rd party library with some of the projects. As before, different developers may have the new library in different paths. How do we set local machine and project specific paths so that we can compile both old and new library projects?
Modifying a project's 'VC++ Directories' changes the project file (.vcxproj) which then poses a problem as we do not want to commit local settings into the repo.
We normally set an environment variable for each library that can be set by each developer in their environment in a env.bat file they run before running devenv (some made up examples) :-
ZLIB_ROOT=c:\somewhere\thirdparty\zlib
BOOST_ROOT=c:\somewhere\thirdparty\boost\version_123
and then in the project files add directories use "$(ZLIB_ROOT)/Include" or "$(ZLIB_ROOT)/Lib/x86" (all made up examples again...)
That way they will resolve correctly for any developer and they can have a different env.bat script for each version
In configuration properties of my project, under the "VC++ directories" there is an entry for "Include Directories". But under "C/C++" option, there is another entry called "Additional Include Directories". Same thing happens with library directories.
What are the difference between these two entries?
This is awkwardness that got introduced in VS2010. The VC++ Directories settings used to be located in Tools + Options, Projects and Solutions, VC++ Directories. Global settings that applied to every project that was built on the machine. It is still there but points out that you should now change it in your project settings. A side-effect of the build engine overhaul in VS2010, enabling building with msbuild. Removing the per-project settings would have been logical but that would break too many existing projects.
As such, it is probably best to treat the VC++ Directories settings as the machine default. It is automatically preset by the VS installer. Tinker with it only if you need an unusual directory search order, putting the custom locations last. Very unusual to do so.
It does work however. And it did get taken advantage of eventually. Empowering the Platform Toolset setting in VS2012 and up. Different compiler, different linker, different #include directories, different linker search path. Modified with just one setting, nice.
CONFIGURING INCLUDE PATHS
VC++ Directories: Include Directories
this value is inherited from the INCLUDE Windows environment variable which is defined outside of Visual Studio
environment variables can be: global to the computer or have user level scope
The INCLUDE and LIB environment variables are created when the Microsoft Windows SDK is installed with Visual Studio.
C/C++: Additional Include Directories
is a project level setting... you will have to define this value for every project in your solution
this value can be persisted to source control
ADDITIONAL NOTES
Which one should I use?
The decision to use Include Directories or Additional Include Directories will depend on your organization's development process. In my opinion, it is more important:
that you are able to consistently and reliably re-create the development environment (think: handing off source code to another developer)
for developers within an organization use a consistent approach
A Note About Macros
The C++ project configuration macros (not to be confused with C++ pre-processor #define directive) inherit content from different sources. Macros like...
$(Include) inherit their values from Windows environment variables
$(OutDir) inherit their values from Visual Studio IDE
REFERENCES
Environment Variables (general introduction)
How to set the path and environment variables in Windows
The Include Directories corresponds to the environment variable INCLUDE.
Directory settings displayed in the window are the directories that
Visual Studio will search for include files referred to in your source
code files. Corresponds to environment variable INCLUDE.
While the Additional Include Directories are passed via a command line argument (i.e. the \I option).
What is the difference between #include <filename> and #include "filename"?
"Include Directories" -> #include <header>
"Additional Include Directories" -> #include "header"
Is there a way to specify include directories in the code, perhaps via a #pragma?
I have my project setup as "src/" and "include/" folders. I am trying to compile in Visual Studio 2010, but I don't want to set it up in the project settings.
Is there another way to allow it to compile instead of having to specify the include as
#include ../include/ss.h
The Correct(tm) way to specify search directories is with compiler flags. In Visual Studio you do this by playing with the project settings, or its compiler's /I commandline parameter.
In Visual studio, you can also define include folders by setting them via Options/File Locations. Then you don't need to repeat them in every project setting. (Assuming that's what you're after). It is a bit weird to define absolute paths in source code, you'll never know from which folder/drive a build is run.
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)
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.
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.
Try setting an environment variable for 'Lib3rdParty' to the appropriate relative path snippet.
..it should be mentioned that using property sheets gets rid of a lot of the clunkyness though