Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Testing outcome from Boost 1.70 on Linux for VxWorks #190

dkrejsa opened this issue May 15, 2019 · 3 comments


Copy link

commented May 15, 2019

I'm trying to build the outcome tests from the Boost 1.70 archive, for VxWorks.
I'm running b2 from the boost_1_70_0/status/ directory.

The source files under libs/outcome/test/tests appear to reference boost outcome header files
using paths like this:

../libs/outcome/test/tests/comparison.cpp:35:10: fatal error: '../../include/boost/outcome/outcome.hpp' file not found
#include "../../include/boost/outcome/outcome.hpp"
1 error generated.
...failed clang-vxworks.compile.c++ ../bin.v2/libs/outcome/test/comparison.test/clang-vxworks/debug/cross-compile-vxworks/link-static/tests/comparison.o...

But there is no 'include' subdirectory in boost_1_70_0/libs/outcome/,
so those relative include paths starting with "../../include/boost/outcome/" do not work.
I tried manually adding a symlink at

cd libs/outcome
ln -s ../.. include

so that the relative include paths would wind up at the headers under boost/outcome,
but that seems to result in some weird behavior where other symlinks are automatically created and for several of them the target and the symlink are the same and the symlinked headers wind up as looping symlinks. Ick.

Note also that there are no Boost files at /usr/include ; for the cross build targeting VxWorks, the include path is set elsewhere via an --includedir=... option for b2.

I'm guessing that outcome is assuming that if the header files are not found at
boost_1_70_0/libs/outcome/include/..., they must be at /somename/include/... in the standard search path.
(For me they are at ${VSB_DIR)/usr/h/public/...).

I can probably find a workaround, but I wanted to bring up the problem. I'm guessing the use of the relative symlinks is due to the different directory layout in the non-boost version of outcome.

@ned14 ned14 added the bug label May 16, 2019


This comment has been minimized.

Copy link

commented May 16, 2019

To be honest, I don't think that anyone considered that people would want to run the unit tests from the Boost end user distro, so nobody raised the fact that it could never work. It works fine from the developer build, obviously, hence

This is very easy to fix, so I shall do so for Boost 1.71. Thank you for reporting the problem, I certainly would not have noticed it without your feedback!


This comment has been minimized.

Copy link

commented May 16, 2019

Thank you!

ned14 added a commit that referenced this issue Jun 17, 2019

This comment has been minimized.

Copy link

commented Jun 17, 2019

Fix passes unit tests. Thanks for reporting it.

@ned14 ned14 closed this Jun 17, 2019

@ned14 ned14 added this to the Boost 1.71 cutoff milestone Jun 17, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.