bjam boost build on windows - changing the path strategy (stage)
I would like to build boost into a prefix directory (.\b2.exe --prefix=C:\prefix) containing "C:\prefix\include\boost\..." and "C:\prefix\lib", just like the linux build does. On Windows it builds into ""C:\prefix\include\boost-1_66\boost\..." instead - is there a bjam control to get rid of the version in the prefix include path for header copies? - Jim
On 11/15/2017 2:54 PM, James E. King, III via Boost wrote:
I would like to build boost into a prefix directory (.\b2.exe --prefix=C:\prefix) containing "C:\prefix\include\boost\..." and "C:\prefix\lib", just like the linux build does. On Windows it builds into ""C:\prefix\include\boost-1_66\boost\..." instead - is there a bjam control to get rid of the version in the prefix include path for header copies?
I use a Windows environment variable to have the starting path set to whatever it needs to be. In Visual Studio it is invoked by $(BOOST_INCLUDE) For example: BOOST_INCLUDE=C:\Boost\include\boost-1_63 Then, when 1.64 is built, the include variable becomes: BOOST_INCLUDE=C:\Boost\include\boost-1_64 Visual Studio only reads environment variables when it first launches. Consequently, if it is already open, please restart it. --Robert
- Jim
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Wed, Nov 15, 2017 at 6:56 PM, Robert via Boost <boost@lists.boost.org> wrote:
On 11/15/2017 2:54 PM, James E. King, III via Boost wrote:
I would like to build boost into a prefix directory (.\b2.exe --prefix=C:\prefix) containing "C:\prefix\include\boost\..." and "C:\prefix\lib", just like the linux build does. On Windows it builds into ""C:\prefix\include\boost-1_66\boost\..." instead - is there a bjam control to get rid of the version in the prefix include path for header copies?
I use a Windows environment variable to have the starting path set to whatever it needs to be. In Visual Studio it is invoked by $(BOOST_INCLUDE)
For example: BOOST_INCLUDE=C:\Boost\include\boost-1_63
Then, when 1.64 is built, the include variable becomes: BOOST_INCLUDE=C:\Boost\include\boost-1_64
Visual Studio only reads environment variables when it first launches. Consequently, if it is already open, please restart it.
--Robert
I am asking for a way for bjam to remove boost-1_66 in the path to the include during the install job because I am going to package up include/ and lib/ into a jfrog repository for a gradle build system. I guess I will just move include/boost-1_66/boost into include/boost and then package it, then move it back so that I can build again incrementally. - Jim
James E. King, III wrote:
I am asking for a way for bjam to remove boost-1_66 in the path to the include during the install job because I am going to package up include/ and lib/ into a jfrog repository for a gradle build system. I guess I will just move include/boost-1_66/boost into include/boost and then package it, then move it back so that I can build again incrementally.
The reason there's boost-1_66 in the include directory on Windows is (I surmise) so that you can install more than one Boost version side by side. Since the version is encoded into the names of the libraries, they can share a single directory, but headers cannot.
On 16/11/2017 14:47, James E. King, III wrote:
I would like to build boost into a prefix directory (.\b2.exe --prefix=C:\prefix) containing "C:\prefix\include\boost\..." and "C:\prefix\lib", just like the linux build does. On Windows it builds into ""C:\prefix\include\boost-1_66\boost\..." instead - is there a bjam control to get rid of the version in the prefix include path for header copies? [...] I am asking for a way for bjam to remove boost-1_66 in the path to the include during the install job because I am going to package up include/ and lib/ into a jfrog repository for a gradle build system. I guess I will just move include/boost-1_66/boost into include/boost and then package it, then move it back so that I can build again incrementally.
FWIW, it's probably controlled by the --layout=versioned setting, but you probably don't want to change this as it also affects the library names. Personally, I just use the stage target and then manually copy the files from stage\lib and include\boost myself; install always ends up doing something weird that I don't like, so I avoid it.
participants (5)
-
degski -
Gavin Lambert -
James E. King, III -
Peter Dimov -
Robert