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
Related
I want to take libFoobar/lib and libFoobar/include and tell VS2017 to make compiling and linking with them work by default for all projects.
In earlier versions there was a global setting for compiler directories but I believe they deprecated that and made it completely project level.
You can manually add a third party library to a project by configuring its project settings
Under C/C++ / additional include directories and linker / input / additional dependencies.
I don't want to have to store or memorize the names and locations of all of the .lib files or /include directories that I might need and manually re-enter them every time I start a new project or have to recreate an existing project.
There may be a way to create and maintain a project template which would be a solution.
You can add .libs to the project from the source code via #pragma comment(lib, "libFoobar.lib"). The most convenient overall method that I've got so far is to add /libFoobar/lib to the PATH variable, add the libs via #pragma to each header file, and manually add the /include directory to each project. But that's a hack.
I did try to use "INCLUDE" and "LIBPATH" environment variables but they did not exist and adding them did nothing:
https://learn.microsoft.com/en-us/cpp/build/reference/cl-environment-variables?view=vs-2019
They might be valid on 2019 only.
Yes, project templates are a thing, and should accomplish this.
Here's some documentation I found by Googling "VS project templates":
How to: Create project templates
Instead of making project templates you can modify the default project property sheets.
Go to View->Other window->Property manager then open one of the nodes for the machine type you are working with (debug and release builds share the actual property sheet file). Right click on Microsoft.Cpp..user and select Properties, you can then make changes just like any other property sheet and the settings will be picked up by projects generated using the default wizards.
This is the replacement system for the mentioned prior global setting.
At the moment I'm using Visual Studio C++ with SFML Graphics, Windows, and System libraries (plus opengl / relevant dependencies).
I'm attempting to sync this project with a group of us who all need to work on it (via GitHub) but it seems (at first glance, at least) like the project file will need different 'include' paths for each person wanting to run the project on their machine. Could get tedious if we're all constantly syncing different settings.
TL;DR: Is there a way to install SFML to the project directory so that the project can be opened and run on any machine without needing to configure the project settings?
As a variant, I'm storing only source in the repository, without project preferences. It also helps in different platforms. I use windows+visual stuido and linux+eclipse.
Or you really can put "include", "lib" folders of SFML into your projects directory like other usual files.
I have two projects in C++ that I need to run and build both in Windows and Linux.
We are using Microsoft TFS for source control.
For windows we are using Visual Studio.
For Linux we are using Eclipse. (I don't have much experience with Eclipse)
I had managed to configure and build properly the projects in both platforms.
I checked in TFS the .cproject and .project from eclipse, so I can use it in another computer.
Now I am trying to get the projects in another Linux computer and I don't know how to do it.
I tried following this instructions, but I don't have my source code zipped.
Other places like here suggest creating a new project.
Isn't there a way to open an existing project in Eclipse similar to Visual Studio?
Do I have to create a new project? If so, how can I keep the configurations I did to be able to build the project so other developer can use them?
File > Import... > General > Existing projects into workspace
Don't select an archive file. Set the root directory to where your .project and .cproject files are located. Your project should show up in the list. Make sure you don't forget to check the checkbox in front of your project.
Committing eclipse project files to a version control system is perfectly fine as long as you don't use absolute paths in your project settings. Use environment variables to specify paths which differ between developer machines.
Background:
I have a program that links to a third party library. There are two versions of the library, so I have created two solutions that point to the same code. This may seem odd, but the code doesn't have to be different. Only the settings within the solution need to be different (i.e. library names are different and the CRT version is different).
SolutionA uses versionA of the third party library (uses CRT version 8.0).
SolutionB uses versionB of the third party library (uses CRT version 9.0).
Both SolutionA and SolutionB point to the same code.
I have set up a Macro in the Project Property Sheets that points to the correct version of the library. The library files are not located within the solution folders. This Macro allows the projects to build correctly.
In order to get the executable to run, I have to tell it where the third party libraries are located. In order to do this, I can go to Configuration Properties-> Debugging -> Environment and add the path to the libraries to the %PATH% environment variable.
Question:
This works fine but is limited to debug mode. How can I add to the %PATH% environment variable in release mode? Can this be done using Project Property Sheets?
Notes: When the program is deployed, a batch file sets up the environment before it runs. However, I would like to be able to run the release executable within Visual Studio to keep things consistent (it would be easier for other developers).
Someone will probably ask why I don't have the libraries in the solution folders or why I don't throw them in with the executable. I hesitant to do so because one version of the libraries takes up about 180 MB. I only need two versions right now, but that is sure to change.
You do not need to create separate solutions with separate properties. For one solution, you can create several configuration. Each configuration have its own compile parameters.
Right Click on your project -> Properties -> Configuration Manager -> New.
Regarding "This works fine but is limited to debug mode". Yes, you are setting parameters for Debug mode only. So this is normal it works in Debug mode only.
For you libraries, if they are static:
Properties -> Linker -> Input -> Additional Dependencies
Properties -> Linker -> General -> Additional Library Directories
The way we've gotten around this problem is to run visual studio itself using a batch file which sets up any environment variables (e.g., PATH) prior to the start of Visual Studio which inherits the environment. This allows for the environment settings to be temporary to the run of VS and inherited across all build configurations.
This works for Debug, Release, and any custom build configurations you may have.
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.