In Visual Studio 2010, how to I set up my VC++ import directories so that I can build my project from multiple machines? For example, my project requires the use of a graphics library that's installed on both of the machines I'm using, but located on different paths.
I imagine the answer is some sort of macro, but I'm new to Visual Studio, so I'm not sure if my intuitions are correct.
I'm transitioning from the Matlab environment, where you can set the path directly per machine, rather than per project. Does Visual Studio have such functionality, or is everything at the level of project properties?
You can indeed use macros to set your include and lib directories on a per machine basis.
if you have your files in your project directory you can use:
$(SolutionDir)\ This will point to the full path of your solution directory root
$(ProjectDir)\ This will point to the full path of your project directory root.
You can place your graphics library in your project directory and point to it like:
$(ProjectDir)\graphicslib, for example, or any other place you want to put it in your solution.
More info is located here http://msdn.microsoft.com/en-us/library/c02as0cs.aspx
use a hierarchy of property sheets, or use a tool like CMake to generate project files for you (as it should automatically find all the libs/includes).
For the property sheets: add the same property sheet to each project. Withing that property sheet, include other property sheets with predefined names. Then on each computer you work, you will have to provide those 'per-machine' propert sheets. For example:
main.vsprops -> include by every project
|- matlab.vsprops -> sets the lib/includes for matlab runtime
|- opengl.vsprops -> sets the lib/include for opengl
Now in your versioning system, you provide a default for matlab.vsprops and opengl.vsprops that contains suitable dfeault values and a batch file to create them. This way you can checkout from the VCS, run a single file, edit the vsprops and start coding without too much hassle. For example:
main.vsprops -> versioned
matlab.vsprops.def -> versioned, contains defaults
opengl.vsprops.def -> versioned, contains defaults
create_vsprops.bat -> versioned, copies *.vsprops.def to *.vsprops
Related
I have solved the GL and GLUT part by installing NVidia CG toolkit. But, having continuous trouble with GLEW, GLFW, GL WTF W, etc.....
I want to install .h, .lib,and, .dll files related to GLUT, GLUI, GLEW, and, GLFW in such a location so that I don't need to pull my hairs every time I create a new project in Visual Studio 2003/2005/2008/2010/2012/20....... .
I am using 64 bit Windows-7.
But, others are bothering and confusing me every time I create a new project.
Create an empty project in which you will once setup once all necessary properties in:
C/C++ -> General -> Additional Include Directories
Linker -> General -> Additional Library Directories
Linker -> Input -> Additional Dependencies
All additional properties if any are required ...
Then, use File -> Export Template from the VS menu to export project template, so you can use it every time you are creating a new project. More information about project templates can be found here:
https://msdn.microsoft.com/library/xkh1wxd8(v=vs.100).aspx
EDIT:
Create an environment variable that will hold the path to your directory which contains the necessary libraries and headers (for example, GL_LIBS). Then, when setting up properties of the project to be exported, use this variable value instead an absolute path (for example: %GL_LIBS%\xyz_headers_dir). This way, if you want to change the location of the libraries, the only thing necessary is to change the environment variable and it will work. This is also helpful in situations when several team members work on the same project and don't want to keep these files in the same location.
One more thing, since "Export template" does not work on VS2010 or older, you will have to do additional steps. In case you are using VS2010, it is only a small issue since there is a VS extension which you can use to export project templates:
https://visualstudiogallery.msdn.microsoft.com/57320b20-34a2-42e4-b97e-e615c71aca24/
If you are using an even older version, then you will have to create a custom wizard which enables you to export a VC++ project template:
https://msdn.microsoft.com/en-IN/library/96xz4cw2(v=vs.90).aspx
I do not advise this at all, since if you want to build a project without these libraries, you'll still have them cluttering up your include paths. This can cause conflicts with other libraries if they happen to use the same include files as one of these. But if you insist...
Visual studio has default paths that every project gets. You can simply add the include and library paths of your choice to these paths. In older versions of Visual Studio, they live in Tools->Options->Projects and Solutions->VC++ Directories or something like that. In newer Visual Studio versions, they live in the VC++ Directories property page of the project/solutions property sheet.
A default install of Visual Studio 2013 creates intermediate and output files in the source tree. This is makes housekeeping harder - I can't just nuke a whole directory to get rid of intermediate files, for example. It also makes it easy to accidentally add a whole bunch of said junk to source control by mistake.
How do you tell VS to put the files elsewhere?
Open your proj file in a text editor, and look for something like this, depending on your platform/configuration:
<OutputPath>bin\x64\Release\</OutputPath>
Change it to whatever path you want it to be.
At build time the locations of these files comes from the $(IntDir) and $(OutDir) build variables. These are defined by shared property sheet entries - shared as in shared by all projects built on a system. Updating that shared property sheet to put them elsewhere is a little tedious but only has to be done once.
For example, to change them such that intermediate files are placed in D:\Obj and output files are placed in D:\Exe:
From the View menu, select PropertyManager.
Expand any project node, e.g. MyProject.
Expand any platform configuration node, e.g. Debug | Win32.
Open the Microsoft.Cpp.Win32.user property sheet.
Select the General section
Set the Intermediate Directory to (note the trailing backslash!)
D:\Obj\$(SolutionName)\$(ProjectName)\$(Platform)\$(Configuration)\
Set the Output Directory to (note the trailing backslash!)
D:\Exe\$(SolutionName)\$(ProjectName)\$(Platform)\$(Configuration)\
Repeat these steps for the remaining platform configuration nodes, e.g. Debug | x64
The property sheets are shared by different build types (e.g. debug, release) within a configuration, but not across platforms. This is why you have to repeat the steps for each platform (e.g. Win32 & x64). But you only have to do this for one project because they all use the same set of property sheets.
BEWARE!
There is a possible issue with this setup. Because the full drive and path is omitted from the directories, if you have more than one copy of a project/solution they will both try to write their output to the same location, possibly leading to horribleness.
My TFS folder structure has project files four layers deep as according to the example structure below. I reference a Dll that is located in the ThirdPartyLib folder and the file is automatically referenced as: ..........\SolutionHoldingFolder\DEV_Region\ThirdPartyLib\Referenced.dll. The problem is that each DEV_Region is mapped in TFS so each developer has a different folder name for the layer above the particular region. So this breaks the build in our automated build and on every other developer's machine.
The reference should not need to go up the file structure that much. The minimum amount and the path that does not break the automated and every other developer's build is: ......\ThirdPartyLib\Referenced.dll. This path is safe when promoted to the upper branches.
How can I have Visual Studio reference file paths in the most minimal way by default instead of the way that will break merges and automated builds?
Example structure:
SolutionHoldingFolder
DEV_Region
ThirdPartyLib
SolutionFolder
LayerFolder1
LayerFolder2
ProjectFolder
ProjectFile
I am using VS2013.
Edit the .*proj files directly and remove the extra indirection (notepad or unload then edit the project).
Visual Studio is considering the position of the solution file as the base, so you can also use ancillary solution to avoid some levels.
I have a directory of source files (.h and .m) that are shared between multiple projects. I'm not building them as a static library; instead, I just include the source in each project.
Previously, I was copying the source into each project independently, but now, I'd like to move to having a single directory that has all of those shared files it, and include a folder reference to them in each XCode project that uses them.
Including them as a folder reference (blue folder) is no problem, and I can add the path to the header includes so that the files in the project can see them. But they're not being built, and thus I'm getting link errors.
How do I get Xcode to build the source in the external directory?
folder references don't work like that in xcode.
this is exactly what an external target (e.g. static library) is for... seems strange that you would choose to duplicate (a portion of) the maintenance for every project. with a library, you can also reduce the build and indexing times (assuming the build settings match some of the time).
if you insist that a static library is a bad idea... you can approximate what you want by creating a custom build script phase for your target (you will need to configure a script, rather than passing the xcode folder reference as input).
Is it possible to build projects to a common directory, instead of the per project bin folder?
The purpose would be to make it easier to source control all my binaries. How can I do it and, what are the pitfalls of this approach?
You have the option to build projects to another directory (a common directory?) rather than the bin/debug and bin/release.
If you mean building your projects and putting the DLL files in a shared folder, yes, we currently do this, but we use this using continuous integration (CI), so we can know when a change in a project caused another project to break.
You may also experience problems when you use a version-specific DLL file as referenced in your other projects.
You can also, rather than having a bat file copy over the DLL files, use Visual-Studio's built in post-build command. It's the same as a batch file, with the exception that no special setup is required in CruiseControl to copy over the files. If a developer makes a change to the post build command it and check it in it will automatically be executed by CruiseControl.
Also, if you'd like your developers to shared the binaries I'd put them in source control to make sure everyone share the same DLL files rather than their own local built copy of the DLL file (which might be different than the actual build server as some compile directives might/might not be defined).
If you mean DLL files/assemblies, then you build to bin/release as usual, then copy the DLL files you require to a common directory and then reference those, so when you rebuild the original solution, you don't have to worry about which version you are using or recompile other related projects as the version hasn't changed in the common dir.
It happens that people build to another folder than bin (e.g. the bin folder in the solution directory rather than the project directory). I doubt you would have any problems doing this. But since you're going to check it in, you must remember to not have it read-only (so you can build over them). Source control programs often lock the files.
You could also consider having a bat script that copies the files to another location after a successful build.
For C++ projects:
Right click on the project -> Properties -> Linker -> Output File
set your directory there.
For C# Projects:
Right click on the project -> Properties -> Builld -> Output Path
I would not put your binary output into source control. Only put the source files, project files and solution files.
We use post-build scripts to copy to the intended location. This works, but is very fiddly (as the scripts are awkward to write & awkward to debug).