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

Update build scripts to support latest boost and ubuntu distros #1997

Closed
wants to merge 1 commit into from

Conversation

Projects
None yet
3 participants
@seelabs
Copy link
Contributor

commented Feb 3, 2017

No description provided.

@seelabs seelabs requested review from mellery451 and ximinez Feb 3, 2017

@mellery451
Copy link
Contributor

left a comment

👍

@ximinez
Copy link
Contributor

left a comment

I just updated to pretty much stock Ubuntu 16.10. I ran the updated Builds/Ubuntu/install_boost.sh, and set $BOOST_ROOT. I also ran

$ sudo Builds/Ubuntu/install_rippled_depends_ubuntu.sh 
[...]
exuberant-ctags is already the newest version (1:5.9~svn20110310-11).
git is already the newest version (1:2.9.3-1).
libprotobuf-dev is already the newest version (3.0.0-7ubuntu3).
pkg-config is already the newest version (0.29.1-0ubuntu1).
protobuf-compiler is already the newest version (3.0.0-7ubuntu3).
libboost-all-dev is already the newest version (1.61.0.2).
python-software-properties is already the newest version (0.96.24.7).
scons is already the newest version (2.5.0-2).
curl is already the newest version (7.50.1-1ubuntu1.1).
libssl-dev is already the newest version (1.0.2g-1ubuntu9.1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

So the depends script is installing libboost 1.61 after going to the trouble of building it. Worse, though, is that cmake (3.5.2) is only finding the system boost.

$ cmake build/cmake/gcc.debug/
[...]
-- Boost version: 1.61.0
-- Found the following Boost libraries:
--   chrono
[...]

You mentioned that cmake needed to be updated to find boost 1.63. Should the install script be doing that? If not, should we be making the user go through yet another step to get this going? Or should we let them rely on the system installed boost 1.61, and leave everything else for advanced users?

@@ -8,6 +8,7 @@
# option.
#


This comment has been minimized.

Copy link
@ximinez

ximinez Feb 7, 2017

Contributor

Nit: Extra line break introduced here.

This comment has been minimized.

Copy link
@seelabs

seelabs Feb 7, 2017

Author Contributor

fixed

@seelabs

This comment has been minimized.

Copy link
Contributor Author

commented Feb 7, 2017

@ximinez I can see three options:

  1. Create a script to install the latest cmake. This requires building from source, and at least on my system I used checkinstall to install it. I'd be mad if a script installed something in the system directories that didn't use the package manager directly. So I don't think that's a good option.

  2. Don't have this script install the latest boost. Set the version to 1.61, or even 1.59 for older systems.

  3. Install the latest boost (1.63). Most users will use the package manager to install boost. If they are running this script, they either need to deal with the ABI issue or they want the latest boost. Yes, this breaks the cmake build unless they install the latest cmake.

I vote (3); (2) seems reasonable. I don't like (1).

@mellery451

This comment has been minimized.

Copy link
Contributor

commented Feb 7, 2017

I'll add an option 3b: install the latest boost (1.63) and then fetch the latest FindBoost.cmake from the cmake repo and install it somewhere (like /opt) where we can search for it ahead of the standard finder modules. This should only require a few lines in the cmake file to manipulate the CMAKE_MODULE_PATH. I don't know if that option is any better, but would make using boost 1.63 slightly more user friendly.

@ximinez

ximinez approved these changes Feb 7, 2017

Copy link
Contributor

left a comment

Data point:

Picking up where I left off last night (CMake 3.5.2, system boost 1.61, boost 1.63 built by these scripts and set as $BOOST_ROOT), I'm basically at option 3.

All the builds work with no ABI issues, including those that didn't work with Ubuntu 16.04 and/or other versions of boost. (gcc/clang, debug/release, unity/classic)

@seelabs seelabs force-pushed the seelabs:ubuntu-build branch from 65219a9 to b698186 Feb 9, 2017

@seelabs seelabs added the Passed label Feb 9, 2017

@seelabs

This comment has been minimized.

Copy link
Contributor Author

commented Mar 1, 2017

In 0.60.0-b7

@seelabs seelabs closed this Mar 1, 2017

@seelabs seelabs deleted the seelabs:ubuntu-build branch Mar 7, 2017

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