Install instructions for Linux

[aelzenaar]

It would be nice to have some install instructions for linux at http://quince-lib.com/preparation/configuring_boost_build.html - I can't get it working, but I saw Ubuntu support mentioned somewhere without any actual instructions.

[mshepanski]

@aelzenaar

Downloading is described here and building is described here. (The page you cited is between those two.)

I'm keen to make sure the document is clear, so I'd appreciate any specifics about how far you got, and where it isn't working for you.

--- Michael

[aelzenaar]

I am attempting to build on Arch Linux. My user-config.jam (/usr/share/boost-build/user-config.jam) is as follows:

use-project /boost : "/usr/share/boost-build" ;

constant libpq-name : "pq" ;
path-constant libpq-include-dir : "/usr/include/postgresql" ;
path-constant libpq-lib-dir : "/usr/lib/postgresql" ;

use-project /quince : "/home/alex/src/quince" ;
use-project /quince-postgresql : "/home/alex/src/quince_postgresql" ;

I have set up boost-build.jam in the level above the quince and quince_postgresql, and it contains:

boost-build /usr/share/boost-build ;

When I try to build the library with b2, I get an error:

$ b2
/usr/share/boost-build/build/project.jam:271: in find-jamfile from module project
error: Unable to load Jamfile.
error: Could not find a Jamfile in directory '/usr/share/boost-build'.
error: Attempted to find it with pattern '[Bb]uild.jam [Jj]amfile.v2 [Jj]amfile [Jj]amfile.jam'.
error: Please consult the documentation at 'http://www.boost.org'.
/usr/share/boost-build/build/project.jam:290: in load-jamfile from module project
/usr/share/boost-build/build/project.jam:68: in project.load from module project
/usr/share/boost-build/build/project.jam:718: in project.use from module project
/usr/share/boost-build/build/project.jam:95: in project.load-used-projects from module project
/usr/share/boost-build/build-system.jam:105: in load-config from module build-system
/usr/share/boost-build/build-system.jam:154: in load from module build-system
/usr/share/boost-build/kernel/modules.jam:261: in import from module modules
/usr/share/boost-build/kernel/bootstrap.jam:132: in boost-build from module
/home/alex/src/boost-build.jam:1: in module scope from module

I assume this means that /usr/share/boost-build is not my boost install directory, but I cannot find any other directories it could be - using /usr as the install directory complains that it cannot find the right files at all (/usr is the actual boost install root directory), and using /usr/share/boost-build seems to be at least finding some files it needs.

I was wondering what you used when building on Linux, as I cannot find any Boost documentation anywhere that seems to be relevant. I also cannot find any Arch Linux packages which might include the files it cannot find.

[mshepanski]

@aelzenaar

The file specified in your boost-build.jam should not be the root of the boost installation. It should be the parent directory of the Boost.Build tool. (As I say here, it should be something that ends with tools/build/v2.) Fwiw, on my ubuntu machine, the content of boost-build.jam is:

boost-build /data/boost_1_55_0/tools/build/v2 ;

If you can't find a directory that ends in tools/build/v2, then you probably don't have Boost.Build on your machine. Even if you have boost, it's possible that you don't have Boost.Build. But both of them are prerequisites for building quince. If you have followed the instructions here, you should have both.

UPDATE 29/08/2014:

For anyone who is using boost 1.56.0 (or later?), replace "tools/build/v2" by "tools/build/src". (I have just updated the online documentation to say this.)

[mshepanski]

I think this is solved, so I'm closing the issue. Feel free to reopen if there is still something wrong.

[aelzenaar]

Thanks for your help - I managed to get it working by installing boost from source,

On Thu, Aug 21, 2014 at 1:16 PM, Michael Shepanski <notifications@github.com

wrote:

I think this is solved, so I'm closing the issue. Feel free to reopen if there is still something wrong.

— Reply to this email directly or view it on GitHub https://github.com/mshepanski/quince/issues/1#issuecomment-52867493.

Alex Elzenaar 2014

[oranja]

Hi, I'm sort of reopening this issue because I am having problems building Quince for a C++ project I'm working on. I will describe the issue and the steps to workaround it, but first I have to be fair and admit that I'm not using exactly the same toolchain as you mention in the docs. My setup is:

• Fedora Workstation 23 (KDE spin, 64bit)
• GCC 5.1.1
• Boost 1.59.0
• SQLite 3.9.2

This is relevant for both master and v1.2. I also peeked at dev and it's safe to predict that same problem will occur there.

The problem is that the compilation of Quince fails with errors of this sort:

/home/oranja/Projects/lib/quince/quince/src/exprn_mappers/exists.cpp: At global scope:
/home/oranja/Projects/lib/quince/quince/src/exprn_mappers/exists.cpp:12:12: error: ‘std::make_unique’ has not been declared
using std::make_unique;

I didn't validate it, but I risk a guess that all of the compilation errors come down to the fact that make_unique was introduced to C++ only in the C++14 standard. Unlike MSVC, and as you already know, g++ won't enable C++14 features automatically. I changed -std=c++11 to -std=c++14 in the jamroot.jam file and the compilation went fine this time. Now the only complaint from gcc is that std::auto_ptr is deprecated (since C++11) with unique_ptr and shared_ptr as heirs.

[mshepanski]

@oranja ,

On the make_unique issue, if you look in quince/include/quince/detail/compiler_specific.h, you will see that there is a workaround for C++ implementations that don't provide this function. The #if line identifies the supported compilers for which this is necessary -- or so I thought. I will look into this more tomorrow, but if a fix needs to be made, that is the place.

On the auto_ptr issue: the cases of it that the compiler is finding aren't in quince, are they?

--- Michael

[oranja]

auto_ptr issues do come from boost. As in too many times, I noticed that but forgot about it by the time I posted the issue. Sorry for the mix up.

As for make_unique, it's your project and you've done an amazing job so far, but IMHO, there shouldn't be a workaround in _detail/compilerspecific.h. As noted here, C++14 is supported by GCC since 4.8. In version 5 I don't see any reason to treat C++14 features with suspicion anymore. However, I can see why there might be a problem for users with older compiler versions if you change the flag from std=c++11 to std=c++14. Couldn't the build flags be updated by b2 with an appropriate check in the jam file? I will look into this tomorrow too and let you know if I found anything, in case you'd be interested.

Edit: This is what I came up with so far: http://pastebin.com/R6pLFUr1 Took me quite a while because I'm new to Boost.Build. There might be a better way to get the same effect. It looks like it does the job of setting the -std flag correctly for both gcc and clang, and should not affect msvc, but I only tested the basic functionality with gcc-5.1.1 and clang-4.2.1. Note that this is only the first part of my suggestion. There is still a problem with clang that is introduced by setting -std=c++14, because clang defines GNUC (and the likes of it) and as a result detail/compiler_specific.h creates an ambiguity for clang, in versions where make_unique is already implemented and can be enabled easily. If you so desire, I can proceed to complete the changes required in compiler_specific.h and test more build environments. Otherwise, I'll get back to my job and write nice data access code with quince.

[mshepanski]

Thanks @oranja.

After some thought, I've come to the view that the cleanest solution is not to switch compilation on and off with #if; nor to switch language versions via Boost.Build; but rather to decide that quince is (for now*) written in C++11, and therefore remove all dependence on library implementations of make_unique(), and provide my own version unconditionally, in namespace quince.

(*) In the future I will probably move to C++14, and require everyone to upgrade their compilers, but that's when I can justify it by doing a bunch of things better; not just std::make_unique(). (E.g. the TODO in query.h.)

[oranja]

This is, IMHO, a very sensible compromise. Thank you for everything.

[mshepanski]

It still needs testing, but it's on the dev branch if you want to take a sneak peek.

[oranja]

I figure you're still working on this, but just to let you know - building from 'dev' fails for now. For example _directmapper.h and collective.h, and there might be more. I only fixed the first one locally to see if my assumption was right. These headers seem to missing an include of "detail/util.h"

best regards, your manual CI assistant ;)

[mshepanski]

So sorry. That's what happens when I do preliminary testing with MSVC. :( Anyhow it should be better now.

[oranja]

It's building fine now. Thanks again.

[mshepanski]

Have merged to main.