linking and including in visual studio
This is kind of a stupid question, and maybe more of a Windows/Visual Studio question than a boost one, but this has been troubling the back of my mind lately. Having learned to write and compile C++ code on Linux, I am always in the habit of explicitly stating the include and library paths for the compiler to search for, as well as the libraries themselves that need to be linked. However, I am revising some Visual Studio projects that use boost and I realized that the path I gave for 'Additional Library Directories' is $(BOOST_ROOT)/lib, but my version of boost hasn't got this directory (it's actually $(BOOST_ROOT)\libs). I then removed all references to boost from 'Additional Library Directories', and 'Additional Include Directories' and the application builds and runs swimmingly. This leads me to believe, that assigning the BOOST_ROOT environment variable in Windows is the only step that is needed for VS's auto linking magic to link correctly to boost. Am I right here, or is there something I am missing? Cheers, David
On Tue, Apr 26, 2016 at 4:14 PM, David Medine <dmedine@ucsd.edu> wrote:
This is kind of a stupid question, and maybe more of a Windows/Visual Studio question than a boost one, but this has been troubling the back of my mind lately.
Having learned to write and compile C++ code on Linux, I am always in the habit of explicitly stating the include and library paths for the compiler to search for, as well as the libraries themselves that need to be linked. However, I am revising some Visual Studio projects that use boost and I realized that the path I gave for 'Additional Library Directories' is $(BOOST_ROOT)/lib, but my version of boost hasn't got this directory (it's actually $(BOOST_ROOT)\libs). I then removed all references to boost from 'Additional Library Directories', and 'Additional Include Directories' and the application builds and runs swimmingly.
This leads me to believe, that assigning the BOOST_ROOT environment variable in Windows is the only step that is needed for VS's auto linking magic to link correctly to boost. Am I right here, or is there something I am missing?
It's been a little while for me, but as far as I can recall, paths are no different, per se, in C++ / Linux, than they are in VS, at least current. The way you set the options in recent VS versions has improved over the years, for sure. And but for path syntax. Other than that, yes, you identify include and linker paths "the same" as you would across platforms. Same in that, yes, you must identify them. After that, also if memory serves, I believe BOOST has the necessary hooks embedded for correct linkage.
Cheers, David _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
David Medine <dmedine@ucsd.edu> wrote:
However, I am revising some Visual Studio projects that use boost and I realized that the path I gave for 'Additional Library Directories' is $(BOOST_ROOT)/lib, but my version of boost hasn't got this directory (it's actually $(BOOST_ROOT)\libs). I then removed all references to boost from 'Additional Library Directories', and 'Additional Include Directories' and the application builds and runs swimmingly.
This leads me to believe, that assigning the BOOST_ROOT environment variable in Windows is the only step that is needed for VS's auto linking magic to link correctly to boost. Am I right here, or is there something I am missing?
In my experience, Visual Studio does not automatically incorporate $BOOST_ROOT (or $(BOOST_ROOT)/lib) into its compile and link search paths. I wouldn't expect it to do that, either. Could it be that you placed a current or previous value of $BOOST_ROOT into other environment variables? I believe that $(IncludePath) and $(LibPath) are used by Microsoft's compile and link tools. Check the values of both. I don't recommend that you get too comfortable with this mysteriously "correct" build behavior. If you have multiple versions of Boost installed, you might not be building with the version you intended. For the time being, you could try displaying your full compile and link commands by changing "Suppress Startup Banner" to "No" in the property pages C/C++ > General and Linker > General. |+| M a r k |+| Mark Stallard Business Application Services Global Business Services Information Technology Raytheon Company (business) 978-436-8487 (cell) 617-331-5443 stallard@raytheon.com 880 Technology Park Drive Billerica, MA 01821 www.raytheon.com This message contains information that may be confidential and privileged. Unless you are the addressee (or authorized to receive mail for the addressee), you should not use, copy or disclose to anyone this message or any information contained in this message. If you have received this message in error, please so advise the sender by reply e-mail and delete this message. Thank you for your cooperation.
On 26 Apr 2016 at 16:51, Mark R Stallard wrote:
I don't recommend that you get too comfortable with this mysteriously "correct" build behavior. If you have multiple versions of Boost installed, you might not be building with the version you intended. For the time being, you could try displaying your full compile and link commands by changing "Suppress Startup Banner" to "No" in the property pages C/C++ > General and Linker > General.
The OP may be referring to the automatic dependency linking facility in MSVC and clang. Boost makes use of it, that's why it may "mysteriously" just work. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Tue, Apr 26, 2016 at 6:21 PM, Niall Douglas <s_sourceforge@nedprod.com> wrote:
On 26 Apr 2016 at 16:51, Mark R Stallard wrote:
I don't recommend that you get too comfortable with this mysteriously "correct" build behavior. If you have multiple versions of Boost installed, you might not be building with the version you intended. For the time being, you could try displaying your full compile and link commands by changing "Suppress Startup Banner" to "No" in the property pages C/C++ > General and Linker > General.
The OP may be referring to the automatic dependency linking facility in MSVC and clang. Boost makes use of it, that's why it may "mysteriously" just work.
As long as the directory settings are correct, yes, I believe that's true.
Niall
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Maybe thiis is not fully helpfull to the above, but I do change the props file in: C:\Users\YOUR USERNAME\AppData\Local\Microsoft\MSBuild\v4.0\Microsoft.Cpp.x64.user.props (other targets in the same folder) to something like the below: <?xml version="1.0" encoding="utf-8"?> <Project DefaultTargets="Build" ToolsVersion="4.0" xmlns=" http://schemas.microsoft.com/developer/msbuild/2003"> <ImportGroup Label="PropertySheets"> </ImportGroup> <PropertyGroup Label="UserMacros" /> <PropertyGroup> <IncludePath>$(VC_X64_INCLUDE);$(BOOST_ROOT);$(IncludePath)</IncludePath> <LibraryPath>$(VC_X64_LIB);$(LibraryPath)</LibraryPath> <ExecutablePath>$(VC_X64_DLL);$(VC_X64_EXE);$(ExecutablePath)</ExecutablePath> <OutDir>$(Platform)\$(Configuration)\</OutDir> <IntDir>$(Platform)\$(Configuration)\</IntDir> </PropertyGroup> <ItemDefinitionGroup> <ClCompile> <WarningLevel>Level4</WarningLevel> <Optimization>MaxSpeedHighLevel</Optimization> <Parallelization>true</Parallelization> <RuntimeLibrary>MultiThreaded</RuntimeLibrary> <UseProcessorExtensions>HOST</UseProcessorExtensions> <ErrorLimit>3</ErrorLimit> </ClCompile> <Link> <OutputFile>$(Platform)\$(Configuration)\$(TargetName)$(TargetExt)</OutputFile> </Link> </ItemDefinitionGroup> <ItemGroup /> </Project> VC_X64_INCLUDE, etc. is env-variable that points to the include folder of my libs (organised linux-style), so I don't need to edit my projects in case I move the libraries folder. Any new project will now automatically include those defaults or (in case of an exisiting project) will default to them, iff you select the default settings in the IDE. Obviously one can add other options to the XML-file. degski
On Wed, Apr 27, 2016 at 1:17 AM, degski <degski@gmail.com> wrote:
Maybe thiis is not fully helpfull to the above, but I do change the props file in:
You're right, that is interesting. That works until you need to rebuild your dev environment. Bottom line is, the settings, directories, etc, should ultimately travel with the project.
C:\Users\YOUR USERNAME\AppData\Local\Microsoft\MSBuild\v4.0\Microsoft.Cpp.x64.user.props (other targets in the same folder)
to something like the below:
<?xml version="1.0" encoding="utf-8"?> <Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <ImportGroup Label="PropertySheets"> </ImportGroup> <PropertyGroup Label="UserMacros" /> <PropertyGroup>
<IncludePath>$(VC_X64_INCLUDE);$(BOOST_ROOT);$(IncludePath)</IncludePath> <LibraryPath>$(VC_X64_LIB);$(LibraryPath)</LibraryPath>
<ExecutablePath>$(VC_X64_DLL);$(VC_X64_EXE);$(ExecutablePath)</ExecutablePath> <OutDir>$(Platform)\$(Configuration)\</OutDir> <IntDir>$(Platform)\$(Configuration)\</IntDir> </PropertyGroup> <ItemDefinitionGroup> <ClCompile> <WarningLevel>Level4</WarningLevel> <Optimization>MaxSpeedHighLevel</Optimization> <Parallelization>true</Parallelization> <RuntimeLibrary>MultiThreaded</RuntimeLibrary> <UseProcessorExtensions>HOST</UseProcessorExtensions> <ErrorLimit>3</ErrorLimit> </ClCompile> <Link>
<OutputFile>$(Platform)\$(Configuration)\$(TargetName)$(TargetExt)</OutputFile> </Link> </ItemDefinitionGroup> <ItemGroup /> </Project>
VC_X64_INCLUDE, etc. is env-variable that points to the include folder of my libs (organised linux-style), so I don't need to edit my projects in case I move the libraries folder.
Any new project will now automatically include those defaults or (in case of an exisiting project) will default to them, iff you select the default settings in the IDE. Obviously one can add other options to the XML-file.
degski
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 28/04/2016 08:44, Michael Powell wrote:
On Wed, Apr 27, 2016 at 1:17 AM, degski <degski@gmail.com> wrote:
Maybe thiis is not fully helpfull to the above, but I do change the props file in:
You're right, that is interesting. That works until you need to rebuild your dev environment. Bottom line is, the settings, directories, etc, should ultimately travel with the project.
Rather than changing that file, I use a hierarchy of props files. (You can attach property files to VS projects via the slightly-hidden View -> Other Windows -> Property Manager.) For example, I have a boost.props file that contains only an import of a specific version props file (eg. <Import Project="boost_1_60_0\boost.props" />) and individual props files in each version dir that contain the actual build settings for that version. This way, projects that should use the latest Boost installed on a given dev PC just link to the base boost.props file, while projects that need a specific version (generally for historic reasons) link to the file in the version-specific directory. (Due to the size of Boost, I usually also have the "real" files on a network share that is mapped to a standard drive letter on different PCs, and another just-import props file in source control that redirects to the appropriate props file on the share; this is what the projects actually link to.) This lets different projects build with different versions of Boost intentionally, and to have a central place to upgrade most projects to the newest Boost version when one is added to the share.
On 27/04/2016 08:14, David Medine wrote:
Having learned to write and compile C++ code on Linux, I am always in the habit of explicitly stating the include and library paths for the compiler to search for, as well as the libraries themselves that need to be linked. However, I am revising some Visual Studio projects that use boost and I realized that the path I gave for 'Additional Library Directories' is $(BOOST_ROOT)/lib, but my version of boost hasn't got this directory (it's actually $(BOOST_ROOT)\libs). I then removed all references to boost from 'Additional Library Directories', and 'Additional Include Directories' and the application builds and runs swimmingly.
This leads me to believe, that assigning the BOOST_ROOT environment variable in Windows is the only step that is needed for VS's auto linking magic to link correctly to boost. Am I right here, or is there something I am missing?
No, there has to be something somewhere supplying the include and library paths. What VS does have (and GCC does not) is auto-linking, which merely allows you to avoid having to explicitly specify the names of the Boost libraries to link with. But this is just the names, not the paths. There are many places that library paths can hide, however; they can include: * the project settings * property sheets imported by the project * the LIBPATH environment variable * Tools -> Options -> Projects and Solutions -> VC++ Directories (on older versions of VS) or the Microsoft.Win32.Cpp.user.props sheet (on newer versions of VS) There might even be a few more than I'm unaware of. :)
On 4/27/2016 9:42 PM, Gavin Lambert wrote:
On 27/04/2016 08:14, David Medine wrote:
Having learned to write and compile C++ code on Linux, I am always in the habit of explicitly stating the include and library paths for the compiler to search for, as well as the libraries themselves that need to be linked. However, I am revising some Visual Studio projects that use boost and I realized that the path I gave for 'Additional Library Directories' is $(BOOST_ROOT)/lib, but my version of boost hasn't got this directory (it's actually $(BOOST_ROOT)\libs). I then removed all references to boost from 'Additional Library Directories', and 'Additional Include Directories' and the application builds and runs swimmingly.
This leads me to believe, that assigning the BOOST_ROOT environment variable in Windows is the only step that is needed for VS's auto linking magic to link correctly to boost. Am I right here, or is there something I am missing?
No, there has to be something somewhere supplying the include and library paths.
What VS does have (and GCC does not) is auto-linking, which merely allows you to avoid having to explicitly specify the names of the Boost libraries to link with. But this is just the names, not the paths.
There are many places that library paths can hide, however; they can include: * the project settings * property sheets imported by the project * the LIBPATH environment variable * Tools -> Options -> Projects and Solutions -> VC++ Directories (on older versions of VS) or the Microsoft.Win32.Cpp.user.props sheet (on newer versions of VS)
There might even be a few more than I'm unaware of. :)
Thanks for this (and to everyone else contributing to this discussion!) For now, I can say with certainty that: 1. there is no reference to boost in the property settings of the project, 2. I'm not using any inherited property sheets, 3. there is no reference to boost in any of my Windows environment variables apart from BOOST_ROOT, and 4. there is no reference to boost in Tools -> Options -> Projects and Solutions -> VC++ Directories. I've attached a buidlog and if you open it and search for 'boost' you will see that there is indeed no reference in the build commands; and yet, if I rename the directory pointed to by BOOST_ROOT, the build will fail to find the boost headers included in the source code. All of which, again, leads me to believe that (unless I am still missing some evil little arcane setting in VS that is working behind my back) setting BOOST_ROOT is all Windows + VS (I'm using 2008 by the way) needs in order to include boost headers and link to the libraries. What I assume is happening is that BOOST_ROOT is a special environment variable that Windows knows about and, if it is defined, Windows will put the correct directories on the global include search paths. Then, based on what headers get included, the autolinker will know what are the right libraries to link with and where to find them (e.g. if you include <boost/thread.hpp> it will automagically know to link to boost_thread-vc90-mt-1_57.lib or whatever the appropriately suffixed binary is). A way to test this is to set up a fresh Windows machine with no environment variables defined, install VS, get the desired version of boost, and try to build before and after setting BOOST_ROOT. If it works after those steps alone, then it works after those steps alone. Cheers, David
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Thu, Apr 28, 2016 at 2:04 PM, David Medine <dmedine@ucsd.edu> wrote:
On 4/27/2016 9:42 PM, Gavin Lambert wrote:
On 27/04/2016 08:14, David Medine wrote:
Having learned to write and compile C++ code on Linux, I am always in the habit of explicitly stating the include and library paths for the compiler to search for, as well as the libraries themselves that need to be linked. However, I am revising some Visual Studio projects that use boost and I realized that the path I gave for 'Additional Library Directories' is $(BOOST_ROOT)/lib, but my version of boost hasn't got this directory (it's actually $(BOOST_ROOT)\libs). I then removed all references to boost from 'Additional Library Directories', and 'Additional Include Directories' and the application builds and runs swimmingly.
This leads me to believe, that assigning the BOOST_ROOT environment variable in Windows is the only step that is needed for VS's auto linking magic to link correctly to boost. Am I right here, or is there something I am missing?
No, there has to be something somewhere supplying the include and library paths.
What VS does have (and GCC does not) is auto-linking, which merely allows you to avoid having to explicitly specify the names of the Boost libraries to link with. But this is just the names, not the paths.
There are many places that library paths can hide, however; they can include: * the project settings * property sheets imported by the project * the LIBPATH environment variable * Tools -> Options -> Projects and Solutions -> VC++ Directories (on older versions of VS) or the Microsoft.Win32.Cpp.user.props sheet (on newer versions of VS)
All I know is where the settings have been moved to, ostensibly, and as they make sense. At some level, they should land in the project settings, not environment settings, not even VS settings.
There might even be a few more than I'm unaware of. :)
Whatever project management plumbing you're using, look forward to seeing your contributions.
Thanks for this (and to everyone else contributing to this discussion!)
For now, I can say with certainty that: 1. there is no reference to boost in the property settings of the project, 2. I'm not using any inherited property sheets, 3. there is no reference to boost in any of my Windows environment variables apart from BOOST_ROOT, and 4. there is no reference to boost in Tools -> Options -> Projects and Solutions -> VC++ Directories.
I've attached a buidlog and if you open it and search for 'boost' you will see that there is indeed no reference in the build commands; and yet, if I rename the directory pointed to by BOOST_ROOT, the build will fail to find the boost headers included in the source code. All of which, again, leads me to believe that (unless I am still missing some evil little arcane setting in VS that is working behind my back) setting BOOST_ROOT is all Windows + VS (I'm using 2008 by the way) needs in order to include boost headers and link to the libraries.
What I assume is happening is that BOOST_ROOT is a special environment variable that Windows knows about and, if it is defined, Windows will put the correct directories on the global include search paths. Then, based on what headers get included, the autolinker will know what are the right libraries to link with and where to find them (e.g. if you include <boost/thread.hpp> it will automagically know to link to boost_thread-vc90-mt-1_57.lib or whatever the appropriately suffixed binary is).
A way to test this is to set up a fresh Windows machine with no environment variables defined, install VS, get the desired version of boost, and try to build before and after setting BOOST_ROOT. If it works after those steps alone, then it works after those steps alone.
Cheers, David
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
What VS does have (and GCC does not) is auto-linking, which merely allows you to avoid having to explicitly specify the names of the Boost libraries to link with. But this is just the names, not the paths.
There are many places that library paths can hide, however; they can include: * the project settings * property sheets imported by the project * the LIBPATH environment variable * Tools -> Options -> Projects and Solutions -> VC++ Directories (on older versions of VS) or the Microsoft.Win32.Cpp.user.props sheet (on newer versions of VS) All I know is where the settings have been moved to, ostensibly, and as they make sense. At some level, they should land in the project settings, not environment settings, not even VS settings.
Hmm, this goes against my hypothesis that BOOST_ROOT and Windows have a special relationship.
Whatever project management plumbing you're using, look forward to seeing your contributions.
I will let you know what I am able to figure out. At this point I think it is worth the time to start from scratch and see where things land. I don't know when I will be able to find the time to do it, though.
On Thu, Apr 28, 2016 at 2:26 PM, David Medine <dmedine@ucsd.edu> wrote:
What VS does have (and GCC does not) is auto-linking, which merely allows you to avoid having to explicitly specify the names of the Boost libraries to link with. But this is just the names, not the paths.
There are many places that library paths can hide, however; they can include: * the project settings * property sheets imported by the project * the LIBPATH environment variable * Tools -> Options -> Projects and Solutions -> VC++ Directories (on older versions of VS) or the Microsoft.Win32.Cpp.user.props sheet (on newer versions of VS) All I know is where the settings have been moved to, ostensibly, and as they make sense. At some level, they should land in the project settings, not environment settings, not even VS settings.
Hmm, this goes against my hypothesis that BOOST_ROOT and Windows have a special relationship.
Whatever project management plumbing you're using, look forward to seeing your contributions.
I will let you know what I am able to figure out. At this point I think it is worth the time to start from scratch and see where things land. I don't know when I will be able to find the time to do it, though.
As I and others have repeated ad nauseam, as long as your directories and such are correctly specified to the project settings, as far as I know, it just works. Mind you, it's been a little while since I've linked anything Boost related, but I don't see why that would have changed in recent months/years.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
As I and others have repeated ad nauseam, as long as your directories and such are correctly specified to the project settings, as far as I know, it just works. Indeed. My concern is that /I don't know why/ my directories are correctly specified to the project settings. They certainly aren't correct in 'Additional Include Directories' and 'Additional Library Search Paths'. As I said before I have no reference to boost in the project settings at all. And yet it works. Hence the head scratching.
Il 28/04/2016 20:38, David Medine ha scritto:
As I and others have repeated ad nauseam, as long as your directories and such are correctly specified to the project settings, as far as I know, it just works. Indeed. My concern is that /I don't know why/ my directories are correctly specified to the project settings. They This can bel solved in an easy way :-D In the properties of your project, under Linker->Command Line you see explicitly what are all the options tha VS passes to the linker, hence all lib include paths.
Best Regards Lorenzo
participants (7)
-
David Medine -
degski -
Gavin Lambert -
Lorenzo Trivelli -
Mark R Stallard -
Michael Powell -
Niall Douglas