How do you configure (i.e. set paths/libs/whatever) for libraries you use in your project (big ones, like boost/qt, which you can't just include in the project files) in Visual Studio when you work with other team members through e.g. SVN? I mean, everyone can have their libraries installed in different paths on their computers, so how do you configure all that to work everywhere?
Right now I'm working on a C++ project so I would like to know about C++ but probably the problem is general.
Basically two options:
Put path to them into an environment variable, you can use then it in project properties
Create a VS user macros with predefined name with path to installed libraries, again it can be used in project properties
To me #1 seems to be simpler and more universal, but no clear winner.
You may also want to include library version into name of variable, so that information about required version of third-party components is versioned as well instead of "whatever is installed on computer".
Related
I have a custom tool that I run on certain file types using the .targets mechanism in Visual Studio 2015.
Projects exist at many levels, and I want to reference this tool when the code is pulled to ANY drive/folder, including the TFS CI agent.
I tried using a relative path, but because the files are at different levels, it doesn't work for all projects.
I tried using a registry setting and environment variable, but that doesn't bode well for the CI machine which might build in a different folder each time.
Is it possible to get the solution folder of which the project/file is in, then I can use a relative path to the tool directory?
All I can find is these properties, which do not seem to help:
General MSBuild properties:
https://msdn.microsoft.com/en-us/library/bb629394.aspx
https://msdn.microsoft.com/en-us/library/ms164309.aspx
Registry and environment variables:
https://msdn.microsoft.com/en-us/library/ms171458.aspx
You can use all the standard tokens within .targets.
Just use
$(SolutionDir)
See https://msdn.microsoft.com/en-us/library/c02as0cs.aspx
Self-service answer: use visual studio's property editing for a vcxproj in preprocessor macros or include paths or such to look at a bunch of available variables. You can usually find what you need in there, by name, or by example, including the one you need here. Better than any documentation.
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.
I am attempting to recreate a set of Fortran projects using Intel Visual Fortran (Parallel Studio XE 2013) with MS Visual Studio 2010. The projects had formerly been built using Compaq Visual Fortran 6.6, where they were all part of a single workspace. There are seven projects in the VS solution (what had been the workspace in CVF), of which three are static libraries and the other four are console applications that depend on the static libraries.
In addition, I have one Fortran module in a single file, in which all the type definitions reside, and which is included by means of the USE statement in each of the source files. In CVF this was included in the workspace as an "External Dependency", but MS VS 2010 does not seem to have the same property for its "solution". (?)
So here's my question: How do I add to the VS solution a .F90 source file that defines a module MODULENAME in such a way that when other source files call USE MODULENAME, the compiler will pull in the module MODULENAME defined in that file. I'll put it wherever MS VS wants me to put it, but I haven't figured out how to tell it where to look.
ANSWER: Thanks to everyone who answered down below. Based on those responses, I created a new static library project that contained the single source file that defines the module in question. I then set dependencies on this project for every other project that had any source files with the USE MYMODULENAME statement in them. Some of them might not have needed this dependency, if they already depended on other projects that depend on this module; I'm not sure about that. It doesn't seem to hurt to have the redundant dependencies; I assume that the IDE resolves this correctly and doesn't compile the module more than once.
For anyone who is as new to this as I am:
To add the module as a project, I right-clicked the solution and selected "Add New Project". In the dialog that popped up, I selected "Static Library" as the type.
To set the dependencies, I right-clicked the solution, selected "Properties" (there's also a button on the Solution Explorer toolbar) and went to the Dependencies panel.
You either:
Create a separate static library project for the single module that has just the single file, and then make projects that require that module/file depend on that static library project (one of the existing static library projects may already be a suitable container for this).
OR
Simply add the single file to each project that uses the module defined by the file.
Which is best mostly depends on what you think is best.
You can find this in Intel Fortran documentation:
use the -I (Linux OS) or /I (Windows OS) option to specify the path to search and locate the definedmod.mod file
So you need to compile your MODULE and accordingly set include directories in other projects Configuration Properties->Fortran->General->Additional Include Directories
There are many open-source libraries that can be compiled with Visual Studio. I'm porting a program from Linux to Windows, but it depends on a number of libraries. I don't know what the best practices regarding libraries are on Windows.
On Linux, these libraries are typically part of the distribution. To use sqlite on Debian, for example, you need only to install libsqlite3-dev and the include files and libraries (both static and dynamic) are automatically installed and available to your program.
If you need a different version than your distribution supplies, you can compile it in your home directory, install it to ~/include and ~/lib, and set the appropriate environment variables so that your compiler includes those directories in its search path.
What is the best way to use libraries that are distributed as source on Windows? If I link dynamically rather than statically, is there an easy way to copy required DLLs into the output directory to ease redistribution (assuming license requirements are met)?
Option 1 - Projects that have binary distributions for windows / do not build in DevStudio.
E.g. OpenSSL.
Projects like OpenSSL are best downloaded to their own folder and built using their own scripts. OpenSSL typically installs itself to C:\OpenSSL on windows builds, so one done, you can add C:\OpenSSL\include and C:\OpenSSL\lib to your project environment to access the OpenSSL headers and Libs. The actual dll files you will need to copy from C:\OpenSSL\bin into your projects staging folder (normally your SolutionDir\Debug or Release).
Once youve gone through the hassle of building OpenSSL once, you don't want to do it again. Or, if you've downloaded the binary distribution, its best left alone. Just document to others which binary distribution you used so they can set up their Visual Studio build environment appropriately.
Option 2 - Small libraries that are easy to create Visual Studio Projects for (or already have). Lua and sqllite fall into this category.
For projects that are small enough, it is not inconvenient to simply add them to your solution in a sub folder. This way you can get their outputs built directly to the solutions output folder, and you do not have to bundle pre-build binary files in your solution making it far easier to share the project with others.
Option 3 - As an alternative you could create your own standardized folder for the products of open source projects. Create C:\oss\include, c:\oss\lib, c:\oss\bin etc, add these paths to DevStudios lib and include paths, add c:\oss\bin to the systems PATH variable, as you build each OSS project, copy the appropriate files to these locations.
Again, while convenient, this setup makes it diffucult to replicate the build environment on a 2nd PC, so you might want to keep the entire C:\oss tree in source control as well.
On windows the easiest way is to build your own DLLs and include them in the program directory.
Yes it uses a bit more space, but HD are large these days and avoids a lot of headaches of incompatible versions (DLL hell). Windows also suffers a few more wrinkles with versions of libs built with different compilers so shipping your own builds is safest
My solution has a library project which needs a special environment to be built (lots of external libraries and tools)... but it is not vital to our application. We'd like to avoid installing these tools when not necessary (most of our developers work on other parts of code).
We have created another project which has the same API, but has an empty implementation and is compilable without those external tools. I'd like to be able to easily switch between those projects and still get all the references in other projects correct.
I don't know VS/MSBuild very well, but willing to learn whatever is necessary. Is it possible? I am looking for ideas... We're using Subversion, and solutions involving some hacks inside VCS are also welcome.
It sounds as if your library project is one that can be separated from your primary solution, taking the tool baggage with it. Doing that, you could build the speciality solution separately, an link the compiled assembly from the main solution.
Create another build-configuration for your project.
So you will have at least 2 build-configurations e.g. Debug_SpecialNeeds and Debug.
For discussion, I'll assume you have a project directory containing your solution file, a "RealLibrary\RealLibrary.csproj" project file (your "real" library, with the dependencies), and a "MockLibrary\MockLibrary.csproj" file (your "mock" library, with the empty implementations).
If I understand correctly, you want to easily "swap" the MockLibrary for the RealLibrary in your solution, and vice-versa.
The easiest/hackiest way to do this, assuming your solution (and dependent projects) are configured to look for the "RealLibrary.csproj" project, is to rename the "RealLibrary" directory (it doesn't matter to what), and rename the "MockLibrary" directory to "RealLibrary" and rename "MockLibrary.csproj" to "RealLibrary.csproj". This will effectively "trick" your solution and dependent projects into loading the "mock library" even though they are referencing the "real library".
A slightly more complex (and perhaps cleaner) solution is to actually modify your "sln" and "csproj" files to reference "MockLibrary.csproj" instead of "RealLibrary.csproj". In the "sln" file, you'll need to change the path to the project in the section near the top:
Microsoft Visual Studio Solution File, Format Version 10.00
# Visual Studio 2008
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "RealLibrary", "RealLibrary\RealLibrary.csproj", "{E1714F9A-E1D9-4132-A561-AE2B4919391C}"
EndProject
You need to change that path "RealLibrary\RealLibrary.csproj" to "MockLibrary\MockLibrary.csproj". If you're going for completeness, you can change the name as well (or perhaps just use a generic name like "Library" for the name).
Likewise, in the dependent csproj files, you'll need to find all instances of the "ProjectReference" node where you reference "RealLibrary.csproj" and modify the path. These sections look like this:
<ProjectReference Include="..\RealLibrary\RealLibrary.csproj">
<Project>{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</Project>
<Name>RealLibrary</Name>
</ProjectReference>
You could relatively easily write some scripts to perform this swap. However, I think there's a deeper problem here that can be addressed more directly. I'll post that as a separate answer, but I wanted you to have the actual answer you were looking for first.
The deeper problem I see here is that your library "needs a special environment to be built", specifically because it depends on "lots of external libraries and tools". I would suggest that you NOT go down the path of creating the mock library, but instead focus on getting the library to build correctly without a special environment. You can achieve this by including all of those dependencies in source control along with your project, and reference those dependencies via relative paths inside your working copy. In my build environments, I try to avoid static environmental dependencies as much as possible (ideally limiting it just to the .NET framework itself).
To get the dependencies into source control, you can either check them directly into the project itself, or you can check them into a different location and then "reference" them in your project via svn:external definitions. In my environment, I have a separate "bin" repository used just for these kind of third party library dependencies, and then many dependent projects can pull them in via externals.
If you can eliminate your library's build-time environmental dependencies, your build will be much more robust and it will be much easier for developers to work with the project.