- Boost-users - lists.preview.boost.org

How to set up user-config.jam properly?
by Robert Dailey 19 Jun '19

19 Jun '19

I am working on a user-config.jam file to build boost 1.70 against Android NDK r19. My jam file looks like this: ``` import os ; local ndk_cxx = [ os.environ CXX ] ; local ndk_ar = [ os.environ AR ] ; local ndk_ranlib = [ os.environ RANLIB ] ; local ndk_flags = [ os.environ CXXFLAGS ] ; using clang : x86 : "$(ndk_cxx)" : <cxxflags>"$(ndk_flags)" <archiver>"$(ndk_ar)" <ranlib>"$(ndk_ranlib)" <architecture>x86 <address-model>32 <binary-format>x86 <abi>x86 ; using clang : armeabi-v7a : "$(ndk_cxx)" : <cxxflags>"$(ndk_flags)" <archiver>"$(ndk_ar)" <ranlib>"$(ndk_ranlib)" <architecture>arm <address-model>32 <binary-format>elf <abi>aapcs ; ``` And my command line is: ``` ./bootstrap.sh --prefix=$INSTALL_DIR/boost || cat bootstrap.log ./b2 -j8 \ --without-python \ --without-test \ target-os=android \ toolset=clang-${ANDROID_ABI} \ variant=release \ threading=multi \ threadapi=pthread \ link=static \ runtime-link=shared \ install ``` When I run the commands above I get: ``` /_build/boost_1_70_0/tools/build/src/build/feature.jam:314: in implied-subfeature from module feature error: "armeabi" is not a known subfeature value of <toolset>clang /_build/boost_1_70_0/tools/build/src/build/feature.jam:497: in feature.validate-value-string from module feature /_build/boost_1_70_0/tools/build/src/build/property.jam:341: in validate1 from module property /_build/boost_1_70_0/tools/build/src/build/property.jam:367: in validate from module property /_build/boost_1_70_0/tools/build/src/build/property.jam:376: in property.validate-property-sets from module property /_build/boost_1_70_0/tools/build/src/build/toolset.jam:187: in toolset.flags from module toolset /_build/boost_1_70_0/tools/build/src/tools/common.jam:447: in common.handle-options from module common /_build/boost_1_70_0/tools/build/src/tools/clang-linux.jam:62: in clang-linux.init from module clang-linux /_build/boost_1_70_0/tools/build/src/build/toolset.jam:44: in toolset.using from module toolset /_build/boost_1_70_0/tools/build/src/tools/clang.jam:33: in clang.init from module clang /_build/boost_1_70_0/tools/build/src/build/toolset.jam:44: in toolset.using from module toolset /_build/boost_1_70_0/tools/build/src/build/project.jam:1104: in using from module project-rules /home/build/user-config.jam:28: in modules.load from module user-config /_build/boost_1_70_0/tools/build/src/build-system.jam:255: in load-config from module build-system /_build/boost_1_70_0/tools/build/src/build-system.jam:453: in load-configuration-files from module build-system /_build/boost_1_70_0/tools/build/src/build-system.jam:607: in load from module build-system /_build/boost_1_70_0/tools/build/src/kernel/modules.jam:295: in import from module modules /_build/boost_1_70_0/tools/build/src/kernel/bootstrap.jam:139: in boost-build from module /_build/boost_1_70_0/boost-build.jam:17: in module scope from module ``` The value of `ANDROID_ABI` is either `x86` or `armeabi-v7a`. What I'm not sure about is this syntax in the JAM file: ``` using <platform> : <subfeature> : <toolchain> ``` Why is this failing? Can someone explain this strange syntax in the JAM file? What is "subfeature" for and what values does it accept? How does this map to the command line arguments? How should I best set up my user config jam file for providing different build parameters per architecture in a cross-compilation setting (building for Android)?

1 1

Re: [Boost-users] [CMake] Specifying name of library file on CMake command line?
by Osman Zakir 17 Jun '19

17 Jun '19

From: Kyle Edwards <kyle.edwards(a)kitware.com> Sent: Monday, June 17, 2019 6:49 PM To: Osman Zakir; cmake(a)cmake.org Subject: Re: [CMake] Specifying name of library file on CMake command line? On Mon, 2019-06-17 at 13:47 +0000, Osman Zakir wrote: >> I want to know how to specify the name of a library I file I want to >> link against. How do I do this? I wanted to build a library with a >> static runtime and static libs; it requires linking against a Boost >> library which I did build with static runtime but when I tried to >> build it, I had linker errors because the dynamic version of the >> library was used instead of the static one. I want to somehow make >> it use the static one. So yeah, how do I do this? Is there a way? >Are you using the FindBoost module? >https://cmake.org/cmake/help/v3.14/module/FindBoost.html >Kyle Yes, I'm using that module. I didn't make any changes to it; it came with the third-party library I'm trying to build.

2 2

Boost.Units: unit type for dBm
by Carel Combrink 17 Jun '19

17 Jun '19

Hi, I have a system that uses dBm to indicate Signal Amplitude, how do I create a type using Boost.Units for this? At the moment I am not concerned about any type of conversions between power and this ratio. Any help will be appreciated. I am already using boost.unit successfully for other units and conversions with the help from the mailing list. I want to now define the correct strong type for this type for consistency. Regards, Carel

2 1

Building Boost.Python for a custom Python installation
by Evan Driscoll 14 Jun '19

14 Jun '19

I have a build of Python I made that was installed (--prefix) at ~/python-3.5.2-asan/. I want to build Boost.Python against it. I have Boost 1.70.0. I have tried a variety of permutations of passing various --with-python options and such to both bootstrap and b2 with no success. Perhaps the closest I've gotten is ./bootstrap.sh --prefix=$HOME/boost-1.70.0/ --with-python=$HOME/python-3.5.2-asan/bin/python3.5 python-debugging=on ./b2 --with-python python-debugging=on -d+2 -j8 cxxflags=-fsanitize=address cflags=-fsanitize=address but with those commands compilation fails because it is looking for include files in ...../include/python3.5/ instead of ..../include/python3.5dm While I'm at it, I had to add cflags and cxxflags explicitly instead of doing what some documentation [1] said to, because: ./b2 --with-python python-debugging=on -d+2 -j8 address-sanitizer=1 /home/evan/Downloads/boost_1_70_0/tools/build/src/build/feature.jam:327: in validate-feature from module feature error: unknown feature "<address-sanitizer>" [1] https://boostorg.github.io/build/manual/develop/index.html#_sanitizers Evan

1 0

[Process] Zombie Processes left behind
by Ryan Ruhge 05 Jun '19

05 Jun '19

Boost Team: We are trying to use boost process to have an always running process spawn child processes in a fire and forget manner (don't wait or block on the process that was just spawned). The issue we are running into is that the child processes become zombie processes when finished until the parent process completes. However in our system the parent process is never intended to complete, it is always running and listening. We have provided code snippets which give a simple example of the symptom we are experiencing. It's an infinite loop (imitating our always running process) that spawns processes that run and then become zombies instead of finishing (I included a sleep so it doesn't spawn processes too quickly). Please advise on whether there is something else we can do, if we are using child or spawn wrong, or if we are using boost process in a manner that it is not intended to be used. Thanks, Ryan Ruhge #include <boost/process.hpp> using namespace std; int main() { while (true) { boost::process::spawn("sleep 10"); sleep(5); } } #include <boost/process.hpp> using namespace std; int main() { while (true) { boost::process::child childProcess("sleep 10"); childProcess.detach(); sleep(5); } }

2 1

Downloads of boost from Bintray.com are temporarily unavailable
by Marshall Clow 30 May '19

30 May '19

Apparently, Boost is being downloaded over 6000 times/day from Bintray, and we've reached the limits of their bandwidth for the month. We're trying to get them to increase our quota (and see if there's someone who is downloading boost over and over again), but at the present time, downloads from bintray are being rejected. Hopefully this will be a temporary situation. -- Marshall (boost release manager)

1 0

Re: [Boost-users] catmull_rom splines
by Nick Thompson 30 May '19

30 May '19

Yes, the Catmull-Rom curve is confusing for scientific application developers because it *creates* a parametrization. For example, if you solved by stepper an ODE y' = f(t,y) and got a solution skeleton {t_i, y_i}, the Catmull-Rom curve *wouldn't accept the time points t_i*. It's only interested in the y_i. Since the Catmull-Rom curve is used in computer graphics, you can kinda see why those guys don't care what the parametrization is. I'm currently working on extending the barycentric rational interpolator into higher dimensions; mathematically it's trivial but getting the interface right is (as always) the real problem. Nick ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, May 30, 2019 8:52 AM, Giorgino R <giorginor21(a)gmail.com> wrote: > Dear Nick/all, > > That was my bad. > > I though that the parametrisation should be in the range [0-1] or [x_min-x_max]. I debugged my program and I saw that Catmull-Rom class internally change the parametrisation from 0 to m_max_s (for normal range 0 -1). Actually, it is explicitly mentioned in the documentation, as well. For some reason, I didn't interpret it properly. I attach my normal spline that now look as expected. > > Apologies for the trouble. It's because I have never had any previous experience with these type of splines. > > Many thanks > Giorgio > > On Thu, May 30, 2019 at 11:07 AM Giorgino R <giorginor21(a)gmail.com> wrote: > >> Dear Nick, >> >> Many thanks for your prompt reply along with your valuable suggestions. >> >> I have now added two ghost points at each end as you described; however, the curve looks (see the attached) more disappointing (always for my objectives :) ). >> To clarify, what I am trying to achieve is to get a (interpolation) line that passes through all the knots/points. Then, for a set of discrete x values (within the space of the line) I want to evaluate the corresponding points and pass them to a boost::linestring. I tried also with both [Cubic B-spline interpolation](https://www.boost.org/doc/libs/1_70_0/libs/math/doc/html/mat… and [Barycentric Rational Interpolation](https://www.boost.org/doc/libs/1_70_0/libs/math/doc/html/mat…. However, my sample points are not equally spaced and non-monotonic (x values). Therefore, I found that Catmull-Rom may be of better use here. >> >> The other issue that is unclear to myself is that the evaluation of a Catmull-Rom spline looks dependent on the parametrisation (see the two images in my first email), as well. >> >> Since in my application I am going to use Boost geometry, I would really like to find a solution on how to interpolate such data point sets with functionality available in Boost. >> >> Once again, many thanks for your support. >> >> Giorgio >> >> On Wed, May 29, 2019 at 6:32 PM Nick Thompson via Boost-users <boost-users(a)lists.boost.org> wrote: >> >>> Hi Giorgino, >>> >>> The strange behavior at the end of the Catmull-Rom splines is a deficiency of the method. However, we are fortunate that this is not a big deficiency. This is because the Catmull-Rom splines are interpolated by functions of compact support, so a point can influence at most four segments (only two, if the point is on the boundary). Looking at your images, I personally don't think they look bad. But presumably since you are writing this, you want better! >>> >>> I would recommend adding two ghost points. Draw a line between point 0 and point 1, and put the ghost point "in the mirror", i.e., place it where point 1 would appear if a mirror sat in the plane passing through P0 and orthogonal to the line joining point zero and point one. You might contend that this is an arbitrary choice, and it is! But the compact support of the basis functions means that the decision is not super important, and this choice will at least give reasonable-looking tangent vectors. >>> >>> Nick >>> >>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ >>> On Wednesday, May 29, 2019 12:08 PM, Giorgino R via Boost-users <boost-users(a)lists.boost.org> wrote: >>> >>>> Hi all, >>>> >>>> I am trying to interpolate some data with a catmull_rom spline available in boost math (interpolation). However, the resulting spline has a strange behavior; especially, at its ends (see the attached image). >>>> Just out of curiosity, I also tried to normalise my data to [0-1] range. However, the line has had even worse behavior (see the attached image). >>>> Below, the c++ code segment of the interpolation is depicted: >>>> >>>> std::vector<std::array<double, 2>> points_intr(16); >>>> >>>> points_intr[0] = { 1.263270, 0.774614 }; >>>> points_intr[1] = { 1.876, 2.480 }; >>>> points_intr[2] = { 1.651110, 4.550 }; >>>> points_intr[3] = { 1.426340, 5.688 }; >>>> points_intr[4] = { 1.429, 7.054 }; >>>> points_intr[5] = { 2.073220, 8.377020 }; >>>> points_intr[6] = { 3.910, 9.140 }; >>>> points_intr[7] = { 6.430, 9.537 }; >>>> points_intr[8] = { 8.950, 9.859 }; >>>> points_intr[9] = { 11.470, 10.317 }; >>>> points_intr[10] = { 12.730, 10.6456 }; >>>> points_intr[11] = { 13.990, 11.0741 }; >>>> points_intr[12] = { 15.335, 11.6928 }; >>>> points_intr[13] = { 16.680, 12.5661 }; >>>> points_intr[14] = { 18.3538, 14.830 }; >>>> points_intr[15] = { 18.700, 16.056 }; >>>> >>>> bm::catmull_rom<std::array<double, 2>> >>>> interpolator_cr(std::move(points_intr)); >>>> >>>> std::vector<double> x_linspace_cr(100); >>>> std::vector<std::array<double, 2>> inter_points(100); >>>> linspace(1.263270, 18.700, 100, x_linspace_cr); // evaluation points along the line >>>> >>>> for (std::size_t i{0}; i < x_linspace_cr.size(); ++i) >>>> { >>>> inter_points[i] = interpolator_cr(x_linspace_cr[i]); >>>> } >>>> >>>> Should I have to add additional (ghost) points at both ends? If yes, is there any optimum way to calculate where exactly to poisition these points? I understand if I get the derivatives at both end I can calculate a straight line that the additional points should lie within. However, how should I calculate the distance from the end points? >>>> >>>> I hope I am not doing anything fundamentally wrong. Any help would be much appreciated. >>>> >>>> Many thanks! >>> >>> _______________________________________________ >>> Boost-users mailing list >>> Boost-users(a)lists.boost.org >>> https://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

catmull_rom splines
by Giorgino R 29 May '19

29 May '19

Hi all, I am trying to interpolate some data with a catmull_rom spline available in boost math (interpolation). However, the resulting spline has a strange behavior; especially, at its ends (see the attached image). Just out of curiosity, I also tried to normalise my data to [0-1] range. However, the line has had even worse behavior (see the attached image). Below, the c++ code segment of the interpolation is depicted: std::vector<std::array<double, 2>> points_intr(16); points_intr[0] = { 1.263270, 0.774614 }; points_intr[1] = { 1.876, 2.480 }; points_intr[2] = { 1.651110, 4.550 }; points_intr[3] = { 1.426340, 5.688 }; points_intr[4] = { 1.429, 7.054 }; points_intr[5] = { 2.073220, 8.377020 }; points_intr[6] = { 3.910, 9.140 }; points_intr[7] = { 6.430, 9.537 }; points_intr[8] = { 8.950, 9.859 }; points_intr[9] = { 11.470, 10.317 }; points_intr[10] = { 12.730, 10.6456 }; points_intr[11] = { 13.990, 11.0741 }; points_intr[12] = { 15.335, 11.6928 }; points_intr[13] = { 16.680, 12.5661 }; points_intr[14] = { 18.3538, 14.830 }; points_intr[15] = { 18.700, 16.056 }; bm::catmull_rom<std::array<double, 2>> interpolator_cr(std::move(points_intr)); std::vector<double> x_linspace_cr(100); std::vector<std::array<double, 2>> inter_points(100); linspace(1.263270, 18.700, 100, x_linspace_cr); // evaluation points along the line for (std::size_t i{0}; i < x_linspace_cr.size(); ++i) { inter_points[i] = interpolator_cr(x_linspace_cr[i]); } Should I have to add additional (ghost) points at both ends? If yes, is there any optimum way to calculate where exactly to poisition these points? I understand if I get the derivatives at both end I can calculate a straight line that the additional points should lie within. However, how should I calculate the distance from the end points? I hope I am not doing anything fundamentally wrong. Any help would be much appreciated. Many thanks!

2 1

bug or documentation missing boost posix_time time_duration not_a_date_time
by Erik Thiele 27 May '19

27 May '19

hi please compile this program: #include <boost/date_time/posix_time/ptime.hpp> #include <iostream> #include <vector> using namespace boost::posix_time; using namespace std; #define x(v) cout << #v << " : " << (v) << '\n'; int main(int argc, char *argv[]) { time_duration a(not_a_date_time); time_duration b; x(a<b); x(a>b); x(a<=b); x(a>=b); x(b<a); x(b>a); x(b<=a); x(b>=a); x(a==b); x(b==a); x(a.is_special()); x(b.is_special()); vector<time_duration> v0, v1; v0.push_back(time_duration()); v0.push_back(time_duration(not_a_date_time)); sort(v0.begin(), v0.end()); v1.push_back(time_duration(not_a_date_time)); v1.push_back(time_duration()); sort(v1.begin(), v1.end()); x(v0==v1); return 0; } the output is: a<b : 0 a>b : 0 a<=b : 1 a>=b : 1 b<a : 0 b>a : 0 b<=a : 1 b>=a : 1 a==b : 0 b==a : 0 a.is_special() : 1 b.is_special() : 0 v0==v1 : 0 if the time_duration datatype is a complete partial order which is for example needed for it to be able to be sorted, then the above output is partly illegal: if not a<b and not b<a then must be a=b. but this is not the case. if a<=b and b<=a then must be a=b. but this is not the case. so as expected the two vectors v0 and v1 are not equal after being sorted even though they certainly should be! i do not understand why time_duration is behaving in such a strange way here. I am using time_duration(not_a_date_time) as a SQL-NULL value just like i am using date(not_a_date_time) and ptime(not_a_date_time) as SQL-NULL values. obviously I should not use time_duration(not_a_date_time). maybe this is the reason why time_duration() != time_duration(not_a_date_time)? I don't understand the design here. for example date()==date(not_a_date_time) and also ptime()==ptime(not_a_date_time) but not with time_duration. why??? why is there no documentation that time_duration is not a complete partial order and thus not sortable - at least when using not_a_date_time? cya erik

2 5

[Boost.Build] configure.builds and check-target-builds always build in debug mode
by David Callu 25 May '19

25 May '19

Hi, I try to add icu support in boost conan package, but on windows with msvc, the build never use icu. During icu detection in boost.locale, the has_icu.exe never build because configure.builds try to build in debug mode when I use property "variant=release" in b2 command line. I can see that in config.log written by b2 during build : b2 use icuucd.lib and icuind.lib instead of icuuc.lib and icuin.lib. So icu is not correctly detected, and so never used. If I bypass the has_icu test, boost locale build fine and have icu backend as expected. This behaviors only fail builds that use different library in release and debug mode, like icu build with msvc. Is it the correct behaviors ? - If yes this is a bad news for library with different library name in release and debug mode. - If no ... houston, we have a problem Best regards David

1 0

[asio] example link dead
by Stephan Menzel 21 May '19

21 May '19

This is just a quick heads up. The website link to a file example in asio: https://www.boost.org/doc/libs/1_70_0/doc/html/boost_asio/example/cpp11/non… ... appears to be dead. 404. HTH... Stephan

3 2

Re: [Boost-users] linker error boost with 1.69 and 1.70
by Danny K 21 May '19

21 May '19

I figured out my problem so please disregard my question. My problem was that zlib and bzip2 support was not being included. I developed a perl script that builds everything for me for Windows & Linux and somehow when the Linux script builds 1.69 or 1.70, it turns off zlib and bzip2 support. Not sure the cause but taking the command my perl script executes and running it the shell outside of perl, boost builds with the proper support for zlib/bzip2 in iostreams. Not sure what the change would be but I have a workaround. wr, Danny

1 0

linker error boost with 1.69 and 1.70
by Danny K 20 May '19

20 May '19

So I have been using boost for awhile. I compile boost the same way for all the versions and have been since 1.48. My platforms are CentOS 6 & 7 and Windows 10 vs2017. My code has compiled on all 3 platforms with Boost without a problem. My current version is 1.66 and I wanted to upgrade to 1.69. Under Windows, I build 1.69 with ZLIB & BZIP and my applications have no problems. I use zlib & bzip in the IOstreams library to read & write compressed files. So I built 1.69 under Linux the same way as I always have but I am now getting a linker error that I don't understand and I am stuck. The error starts with: API_utiltyFunctions.cpp:(.text+0x154): undefined reference to `boost::iostreams::detail::zlib_base::before(char const*&, char const*, char*&, char*)' API_utiltyFunctions.cpp:(.text+0x15b): undefined reference to `boost::iostreams::zlib::sync_flush' API_utiltyFunctions.cpp:(.text+0x165): undefined reference to `boost::iostreams::detail::zlib_base::xinflate(int)' API_utiltyFunctions.cpp:(.text+0x177): undefined reference to `boost::iostreams::detail::zlib_base::after(char const*&, char*&, bool)' API_utiltyFunctions.cpp:(.text+0x17e): undefined reference to `boost::iostreams::zlib_error::check(int)' API_utiltyFunctions.cpp:(.text+0x185): undefined reference to `boost::iostreams::zlib::stream_end' The boost portion of my linker line is: -L[ path to boost 1.69] \ -lboost_random-1_69 \ -lboost_program_options-1_69 \ -lboost_date_time-1_69 \ -lboost_chrono-1_69 \ -lboost_regex-1_69 \ -lboost_thread-1_69 \ -lboost_exception-1_69 \ -lboost_filesystem-1_69 \ -lboost_system-1_69 \ -lboost_iostreams-1_69 -lrt -lbz2 -lz -lm Any help would be appreciate. Weirdly if I revert back to boost 1.66, I don't have a problem. I also tested this compilation against boost 1.70 and I get the same problem. I do compile boost statically with shared runtime libraries and threads. Respectfully, Danny K

1 0

[variant2] Acceptance conditions met - Targeted for 1.71.0
by Michael Caisse 16 May '19

16 May '19

Peter Dimov has updated the Variant2 library based on review acceptance criteria. I have reviewed the changes and "OK" Variant2 to be included as a Boost library. My understanding is that Peter is targeting Variant2 to be available in the 1.71.0 release. Congratulations Peter! Thank you for your quick work in updating the library based on the review feedback. -- Michael Caisse Ciere Consulting ciere.com

1 0

Building boost 1_70_0 with PGI 18.5 on CentOS 7
by Christopher Harrop - NOAA Affiliate 16 May '19

16 May '19

Hi, I am having trouble building Boost 1_70_0 with PGI 18.5 on a Linux CentOS 7 system, and I am wondering if anyone has suggestions about how to get it working. I spent some time searching online for answers, but didn’t find anything recent that applied to my problem. I am a novice with boost, and so am not sure where to start digging for solutions. I have no issues with GCC or Intel compilers. My procedure, after I untar and cd into the boost directory, is as follows: ./bootstrap.sh --with-toolset=pgi —prefix=/path/to/install/boost export BUILD_TYPE=complete export LIBRARY_NAME=versioned export LIBRARY_TARGETS=shared,static ./b2 -j 12 install --build-type=${BUILD_TYPE} --layout=${LIBRARY_NAME} --target=${LIBRARY_TARGETS} This procedure appears to work fine for the intel-linux and gcc toolsets. But, for pgi, I get this: ==================================== +./bootstrap.sh --with-toolset=pgi --prefix=/path/to/install/boost Building Boost.Build engine with toolset pgi... tools/build/src/engine/bin.linuxx86_64/b2 Detecting Python version... 2.7 Detecting Python root... /usr Unicode/ICU support for Boost.Regex?... /usr Generating Boost.Build configuration in project-config.jam for pgi... Bootstrapping is done. To build, run: ./b2 To generate header files, run: ./b2 headers To adjust configuration, edit 'project-config.jam'. Further information: - Command line help: ./b2 --help - Getting started guide: http://www.boost.org/more/getting_started/unix-variants.html - Boost.Build documentation: http://www.boost.org/build/ + export BUILD_TYPE=complete + BUILD_TYPE=complete + export LIBRARY_NAME=versioned + LIBRARY_NAME=versioned + export LIBRARY_TARGETS=shared,static + LIBRARY_TARGETS=shared,static + ./b2 -j 12 install --build-type=complete --layout=versioned --target=shared,static Performing configuration checks - default address-model : none - default architecture : none /scratch4/BMC/gsd-hpcs/Christopher.W.Harrop/bass-develop/build/boost/1.70.0/pgi/18.5/tools/build/src/tools/common.jam:977: in toolset-tag *** argument error * rule numbers.less ( n1 n2 ) * called with: ( 4 ) * missing argument n2 ==================================== Based on some suggestions I found online from others having similar errors, I edited tools/build/src/tools/common.jam to comment out these lines (977-980): # From GCC 5, versioning changes and minor becomes patch # if $(tag) = gcc && [ numbers.less 4 $(version[1]) ] # { # version = $(version[1]) ; # } This results in the following failure, which I’ve truncated because it’s really long: ==================================== + ./bootstrap.sh --with-toolset=pgi --prefix=/scratch4/BMC/gsd-hpcs/Christopher.W.Harrop/bass-develop/opt/boost/1.70.0/pgi/18.5 Building Boost.Build engine with toolset pgi... tools/build/src/engine/bin.linuxx86_64/b2 Detecting Python version... 2.7 Detecting Python root... /usr Unicode/ICU support for Boost.Regex?... /usr Generating Boost.Build configuration in project-config.jam for pgi... Bootstrapping is done. To build, run: ./b2 To generate header files, run: ./b2 headers To adjust configuration, edit 'project-config.jam'. Further information: - Command line help: ./b2 --help - Getting started guide: http://www.boost.org/more/getting_started/unix-variants.html - Boost.Build documentation: http://www.boost.org/build/ + export BUILD_TYPE=complete + BUILD_TYPE=complete + export LIBRARY_NAME=versioned + LIBRARY_NAME=versioned + export LIBRARY_TARGETS=shared,static + LIBRARY_TARGETS=shared,static + ./b2 -j 12 install --build-type=complete --layout=versioned --target=shared,static Performing configuration checks - default address-model : none - default architecture : none error: No best alternative for libs/context/build/asm_sources next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>elf <threading>multi <toolset>qcc not matched next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>mach-o <threading>multi <toolset>clang not matched next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>mach-o <threading>multi <toolset>darwin not matched next alternative: required properties: <abi>aapcs <address-model>32 <architecture>arm <binary-format>pe <threading>multi <toolset>msvc not matched next alternative: required properties: <abi>aapcs <address-model>64 <architecture>arm <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>aapcs <address-model>64 <architecture>arm <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>aapcs <address-model>64 <architecture>arm <binary-format>mach-o <threading>multi <toolset>clang not matched next alternative: required properties: <abi>aapcs <address-model>64 <architecture>arm <binary-format>mach-o <threading>multi <toolset>darwin not matched next alternative: required properties: <abi>o32 <address-model>32 <architecture>mips1 <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>o32 <address-model>32 <architecture>mips1 <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>n64 <address-model>64 <architecture>mips1 <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>n64 <address-model>64 <architecture>mips1 <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>mach-o <threading>multi <toolset>darwin not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>xcoff <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>power <binary-format>xcoff <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>mach-o <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>mach-o <threading>multi <toolset>darwin not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>xcoff <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>power <binary-format>xcoff <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>32_64 <architecture>power <binary-format>mach-o <threading>multi not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>elf <threading>multi <toolset>intel not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>32 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>darwin not matched next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>clang not matched next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>clang-win not matched next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>intel not matched next alternative: required properties: <abi>ms <address-model>32 <architecture>x86 <binary-format>pe <threading>multi <toolset>msvc not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>intel not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>clang not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>darwin not matched next alternative: required properties: <abi>sysv <address-model>64 <architecture>x86 <binary-format>mach-o <threading>multi <toolset>intel not matched next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>clang not matched next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>clang-win not matched next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>intel not matched next alternative: required properties: <abi>ms <address-model>64 <architecture>x86 <binary-format>pe <threading>multi <toolset>msvc not matched next alternative: required properties: <abi>x32 <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>clang not matched next alternative: required properties: <abi>x32 <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>gcc not matched next alternative: required properties: <abi>x32 <address-model>64 <architecture>x86 <binary-format>elf <threading>multi <toolset>intel not matched next alternative: required properties: <abi>sysv <address-model>32_64 <architecture>x86 <binary-format>mach-o <threading>multi not matched next alternative: required properties: <abi>sysv <architecture>combined <binary-format>mach-o <threading>multi not matched - C++11 mutex : no - lockfree boost::atomic_flag : no - Boost.Config Feature Check: cxx11_auto_declarations : no - Boost.Config Feature Check: cxx11_constexpr : no - Boost.Config Feature Check: cxx11_defaulted_functions : no - Boost.Config Feature Check: cxx11_final : no - Boost.Config Feature Check: cxx11_hdr_mutex : no - Boost.Config Feature Check: cxx11_hdr_tuple : no - Boost.Config Feature Check: cxx11_lambdas : no - Boost.Config Feature Check: cxx11_noexcept : no - Boost.Config Feature Check: cxx11_nullptr : no - Boost.Config Feature Check: cxx11_rvalue_references : no - Boost.Config Feature Check: cxx11_template_aliases : no - Boost.Config Feature Check: cxx11_thread_local : no - Boost.Config Feature Check: cxx11_variadic_templates : no - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - zlib : no - bzip2 : no - lzma : no - zstd : no - iconv (libc) : no - iconv (separate) : no - icu : no - icu (lib64) : no - Boost.Locale needs either iconv or ICU library to be built. - Boost.Locale needs either iconv or ICU library to be built. - native-atomic-int32-supported : no - native-syslog-supported : no - pthread-supports-robust-mutexes : no - x86 : no - arm : no - mips1 : no - power : no - sparc : no - gcc visibility : no - long double support : no warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. - libbacktrace builds : no - addr2line builds : no - WinDbg builds : no - WinDbgCached builds : no - BOOST_COMP_GNUC >= 4.3.0 : no error: No best alternative for libs/context/build/asm_sources ### similar messages to the above repeat several times and I’ve left it out for clarity and length, then output continues below ### Component configuration: - atomic : building - chrono : building - container : building - context : building - contract : building - coroutine : building - date_time : building - exception : building - fiber : building - filesystem : building - graph : building - graph_parallel : building - headers : building - iostreams : building - locale : building - log : building - math : building - mpi : building - program_options : building - python : building - random : building - regex : building - serialization : building - stacktrace : building - system : building - test : building - thread : building - timer : building - type_erasure : building - wave : building ...patience... ...patience... ...patience... ...patience... ...patience... ...found 45809 targets... ...updating 17951 targets... gcc.compile.c++ bin.v2/libs/regex/build/gcc/debug/threading-multi/visibility-hidden/posix_api.o /bin/sh: line 1: -fvisibility-inlines-hidden: command not found -fvisibility-inlines-hidden -fPIC -pthread -O0 -fno-inline -Wall -g -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_REGEX_DYN_LINK=1 -I"." -c -o "bin.v2/libs/regex/build/gcc/debug/threading-multi/visibility-hidden/posix_api.o" "libs/regex/build/../src/posix_api.cpp" ...failed gcc.compile.c++ bin.v2/libs/regex/build/gcc/debug/threading-multi/visibility-hidden/posix_api.o... gcc.compile.c++ bin.v2/libs/regex/build/gcc/debug/threading-multi/visibility-hidden/c_regex_traits.o /bin/sh: line 1: -fvisibility-inlines-hidden: command not found -fvisibility-inlines-hidden -fPIC -pthread -O0 -fno-inline -Wall -g -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_REGEX_DYN_LINK=1 -I"." -c -o "bin.v2/libs/regex/build/gcc/debug/threading-multi/visibility-hidden/c_regex_traits.o" "libs/regex/build/../src/c_regex_traits.cpp" ...failed gcc.compile.c++ bin.v2/libs/regex/build/gcc/debug/threading-multi/visibility-hidden/c_regex_traits.o... gcc.compile.c++ bin.v2/libs/regex/build/gcc/debug/threading-multi/visibility-hidden/instances.o /bin/sh: line 1: -fvisibility-inlines-hidden: command not found -fvisibility-inlines-hidden -fPIC -pthread -O0 -fno-inline -Wall -g -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_REGEX_DYN_LINK=1 -I"." -c -o "bin.v2/libs/regex/build/gcc/debug/threading-multi/visibility-hidden/instances.o" "libs/regex/build/../src/instances.cpp" ==================================== Chris ----------------------------------------------------------------------------------------------------------- Christopher W. Harrop email: christopher.w.harrop(a)noaa.gov <mailto:christopher.w.harrop@noaa.gov> Global Systems Division voice: (303) 497-6808 <tel:%28303%29%20497-6808> NOAA Earth System Research Laboratory fax: (303) 497-7259 <tel:%28303%29%20497-7259> 325 Broadway R/GSD2 Boulder, CO 80303

3 4

[stacktrace]stacktrace print nothing on x86.
by Hao Jiang 16 May '19

16 May '19

Hello everyone, I found boost::stacktrace print no information on my machine in RELEASE mode when target is x86, i.e. the size of stacktrace is zero. But if target switched to x64, stacktrace worked fine. Is anyone knows the reason? OS: Windows 7(64) Compiler: MSVC 14 Boost ver. :1.67/1.69 Stacktrace config: BOOST_STACKTRACE_USE_WINDBG(_CACHED) Thanks, Hao Jiang.

1 0

Boost Graph write_grahml - wrong source- and target-ID's in edge of XML-File
by lila 13 May '19

13 May '19

Hi there, I want to create an xml-file out of my Graph... So I'm using the write_graphml Function with dynamic_properties. Everything is fine, I get a file, but there are wrong source- and target- ID's in the edge structs ... Here an example: <node id="n1"> <data key="key0">vertex_7</data> <data key="key2">bf88aa63-bff1-5c04-8daf-37a5e31981f6</data> <data key="key6">12.5</data> <data key="key7">7.5</data> </node> <edge id="e1" source="n1" target="n2"> <data key="key1">edge_4_5</data> <data key="key3">26c512cb-46d8-5eb5-8021-2aac9f492227</data> <data key="key4">45844430-f1ea-5355-b7ce-eb566fe89256</data> <data key="key5">ecac63d6-e531-5ce8-9578-13cb63d040de</data> </edge> In the edge there is the wrong source-ID - it should be the ID of Vertex 4 (source="n0") not 7 (source="n1") My Graph: struct vertex { float x; float y; string name; string uuid; }; struct edge { string source_v_uuid; //startpoint uuid string target_v_uuid; //endpoint uuid string name; // name - edge_from_src-Vertex_to_dest-Vertex string uuid; }; typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, vertex, edge> myGraph; And my Properties: boost::dynamic_properties dyn_p; // fill vertex properties dyn_p.property("name", get(&vertex::name, graph)); dyn_p.property("x-value", get(&vertex::x, graph)); dyn_p.property("y-value", get(&vertex::y, graph)); dyn_p.property("uuid", get(&vertex::uuid, graph)); // fill edge properties dyn_p.property("name", get(&edge::name, graph)); dyn_p.property("v-src-uuid", get(&edge::source_v_uuid, graph)); dyn_p.property("v-dest-uuid", get(&edge::source_v_uuid, graph)); dyn_p.property("uuid", get(&edge::uuid, graph)); write_graphml(ofs, graph, dyn_p, true); I tried to create a property map by myself to set the UUID as the (vertex (source/target)) -ID's, but that changed nothing, there are still wrong source- and target- ID's in the edge struct. auto map = get(&vertex2::uuid, graph); write_graphml(ofs, graph, map, dyn_p, true); Can anybody help me? Or even give me a hint to figure out what is going wrong? -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Users-f2553780.html

1 0

[variant2] Review Results
by Michael Caisse 11 May '19

11 May '19

First, I would like to apologize to Peter and the those who took time to review Boost.Variant2 for the slow turn-around of a result. Thank you Peter for producing and submitting such a high-quality library for review. The code has been a pleasure to read and review. Thank you to the reviewers! Your participation in the process is what makes Boost libraries high-quality. I personally appreciate the time and effort that each of you have put into this review. ------------- Result ------------- Boost.Variant2 will be ACCEPTED after the following changes are made. An additional review will not be required. - The library will implement the strong guarantee: - If all alternatives have nothrow move, single buffer - else, double buffer - Improved documentation: - Addition of a tutorial - Addition of design motivation - Peter has indicated that triviality propagation will come in a future version. The initial Boost release need not support triviality propagation. - Expected will not be included but may be submitted for review at another time. ---------------- Review Verdicts ---------------- The following people provided reviews. Reject ---------- Andrezj Krzemienski Antony Polukhin Jan Herrmann Accept ---------- Emil Dotchevski Gavin Lambert Phil Endecott Conditionally Accept -------- Bjorn Reese Andrey Semashev Damian Jarek Niall Douglas Andrezj and Antony’s rejections were based on not having a valueless-by-exception state. Neither saw the selected design space worth considering and each believed the trade-off was dangerous for users. The Conditional Acceptance reviews voiced the following: - Strong preference for the strong guarantee (and therefore no need to provide “surprising” behaviour for the state after an exception.) - Improved documentation containing both tutorial and motivation sections. - Triviality propagation of the variant types. - Accepted without expected being contained. -------------- Some Thoughts -------------- There was a good amount of healthy discussion on the Developer Mail List concerning Variant2. I want to thank all of the participants for engaging with civility and keeping to the technical merits despite the galvanized opinions concerning valueless-by-exception and the basic exception guarantee. Over the past couple weeks I have re-read all of the discussion threads 3 or 4 times. While some people didn’t find value in the exchanges, this level of engagement about design trade-offs is one of the attributes that sets Boost reviews apart. They are not merely reviews discussing the quality of implementation but also the intricacies of design choices within the constraints and consistency of the language. When reviewers articulate their opinions the entire community learns and grows. The trade-offs that Peter made seem dangerous to some yet the exact correct formulation for others. There are even standard library implementers that don’t agree with std::variant’s valueless-by-exception. A high-quality variant that provides the strong exception guarantee is a type that has been missing from the programmer toolbox. Variant2 provides this. I will make an additional announcement to the community when the conditions for acceptance have been met. Thank you all for making Boost better! michael -- Michael Caisse Ciere Consulting ciere.com -- Michael Caisse Ciere Consulting ciere.com

1 0

filesystem::path crash on Windows when dealing with umlauts ( üëï )
by Gonzalo Garramuño 09 May '19

09 May '19

I am getting a crash on Windows when passing a path that contains umlauts (like sampëüö ) to the path constructor. I tried boost 1.69 and boost 1.60. Here's the code I am using: namespace fs = boost::filesystem; const char* tmp = setlocale(LC_ALL, N_("")); // Create and install global locale std::locale::global(boost::locale::generator().generate( N_("") )); // Make boost.filesystem use it fs::path::imbue(std::locale()); if ( !tmp ) tmp = setlocale( LC_ALL, NULL ); std::string program = argv[0]; fs::path file = fs::path( program ); // CRASH -- Gonzalo Garramuño

3 2

A property_tree like structure where key is also value?
by Jeanette C. 05 May '19

05 May '19

Hey hey, I need a hirarchical data representation in my program, which is well modelled by boost.property_tree, but my keys will also be my values. The tree will have a fixed depth, all keys/values are std::string and I expect maybe a few hundred leaves and maybe a hundred or so nodes in between. Is it worth looking for a different structure at all, considering that the program is designed for desktop systems? If so: is there another Boost library that would serve me better? Best wishes and thanks for any tips, Jeanette -- * Website: http://juliencoder.de - for summer is a state of sound * SoundCloud: https://soundcloud.com/jeanette_c * Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g * GitHub: https://github.com/jeanette-c * Twitter: https://twitter.com/jeanette_c_s I'm not that innocent... <3 (Britney Spears)

1 0

[Boost.Asio coroutines] Question about HTTPServer4 examples
by daniil＠daniil.it 01 May '19

01 May '19

1 1

Using Boost 1.63 and 1.66 together with GNU unique global objects
by Jamie Jason 30 Apr '19

30 Apr '19

Apologies if this is a newbie question, but I have done my best to search Google, etc., and haven't been able to find a solution. The project I am working on uses Boost 1.63 statically linked and a third-party shared library that uses Boost 1.66 statically linked on CentOS 7. For reasons that are beyond my control, these are the versions that must be used. I am running into a problem with g++ 4.5.8 and the GNU extension to ELF for unique global symbols. Take as example the function get_netdb_category() in boost/asio/impl/error.ipp. The function has a static boost::asio::error::detail::netdb_category object that it returns a const reference to. When I use nm to inspect the main executable the symbol appears in the data segment and the type for boost::asio::error::detail::netdb_category()::instance is "u", which indicates that the compiler has marked this as a globally-unique symbol. The problem occurs when the loader loads the third-party shared library. Because the symbol boost::asio::error::detail::netdb_category()::instance has been marked as unique in the shared library as well (verified by running readelf on the .so), the loader decides that it will simply use the one from the executable. Because the shared library's version of the object is larger than the executable's version, when it is constructed it overwrites the 16 bytes beyond the end of the executable's object, trashing the contents of the data segment that were there previously. I tried using the -fno-gnu-unique flag when compiling our executable, but that doesn't fix the problem - it marks the symbol as weak in the main executable, but the shared library, because I cannot re-compile, still has the symbol marked as unique. I tried using dlopen with RTLD_LOCAL and that fixes the problem of overwriting the main executable's memory, however the corresponding symbols in the shared library have pointers back into the main executable's data segment (where the corresponding netdb_category static lives), which means that when if the shared library accesses these objects it will be following invalid pointers as it will overlay a larger v1.66 object onto a smaller v1.63 object. Has anyone encountered a problem like this? And, if so, did you find a good solution? Much thanks, Jamie

4 4

[locale] gettext functions: std::locale default argument not working
by Jeanette C. 29 Apr '19

29 Apr '19

Hey hey, it appears that the std::locale const &loc=std::locale() argument of the gettext functions for direct message translation doesn't properly pick up the program's global locale. Assume that messages have been extracted and translated. Consider the code snippet below: ... boost::locale::generator gen; std::locale loc = gen("de_DE"); std::locale::global(loc); // std::locale loc2; // will also work as argument to gettext string s = boost::locale::gettext("Hello world"); // output "Hello world" string t = boost::locale::gettext("Hello world",loc); // output "Hallo Welt" ... I am on boost 1.69.0-2, Arch Linux package, gcc 8.2.1, libstdc++ 6.0.25 (taken from the dynamic library filename), this is distributed with the GCC package. I'd appreciate any hint to solve this, since it would mean a lot of code editing otherwise. Best wishes and thanks, Jeanette -- * Website: http://juliencoder.de - for summer is a state of sound * SoundCloud: https://soundcloud.com/jeanette_c * Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g * GitHub: https://github.com/jeanette-c * Twitter: https://twitter.com/jeanette_c_s Cinderella's got to go <3 (Britney Spears)

1 0

[locale] Using generator with std::locale always yields name *
by Jeanette C. 29 Apr '19

29 Apr '19

Hey hey, When I use the boost::locale::generator to initialise an std::locale the std::locale.name() always yields "*". Examples: ... boost::locale::generator gen; std::locale loc = gen("en_US"); std::cout << loc.name(); ... output: * Whereas using the std::locale constructor with const char * yields the proper name: ... std::locale loc("en_US"); std::cout << loc.name(); ... Output: en_US I am running on Arch Linux, with Boost version 1.69.0-2 (the latest version in the official Arch package repositoy). Is there a caveat I overlooked or is there another way around this behaviour? One word of praise: the Boost locale library gave me the first pleasant experience of using localisation. I love the interface and think it very understandable even for a programmer of only mediocre level like myself. So: thank you! Best wishes, Jeanette -- * Website: http://juliencoder.de - for summer is a state of sound * SoundCloud: https://soundcloud.com/jeanette_c * Youtube: https://www.youtube.com/channel/UCMS4rfGrTwz8W7jhC1Jnv7g * GitHub: https://github.com/jeanette-c * Twitter: https://twitter.com/jeanette_c_s I thought love was just a tingling of the skin <3 (Britney Spears)

2 2

Windows batch file to build for multiple compiler versions
by Kenneth Porter 25 Apr '19

25 Apr '19

Here's the batch file I use to build the binary libraries for each new version of Boost for all the compilers and architectures my own library supports. Suggestions for improvements are welcome. Just define the boost_root environment variable and run it. https://gist.github.com/SpareSimian/2a0f1fd1718d81ce2441218ded776778

2 1