rivet is hosted by Hepforge, IPPP Durham
close Warning: Can't synchronize with repository "(default)" (Repository path '/hepforge/hg/rivet/public/rivet' does not exist.). Look in the Trac log for more information.

Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#227 closed defect (fixed)

Boost path not correct

Reported by: jmonk Owned by: Andy Buckley
Priority: critical Milestone: Version 1.1.2
Component: General Version:
Keywords: Cc: Andy Buckley, hoeth


The boost header path that configure needs in order to succeed is not compatible with the #include "boost/foreach.hpp" that is in RivetBoost?.hh . My boost is installed in /usr/local/include/boost-1_34_1/boost/foreach.hpp and I have to configure with


but then it doesn't find boost/foreach.hpp. Obviously I could just change the configure macro to look for boost/foreach.hpp, but I suspect that might mess someone else up.

Change History (5)

comment:1 Changed 12 years ago by Andy Buckley

It should be set up so that this works:


i.e. the "incpath" is the path that gets used as the -I compiler argument. Does that not work? If not, please try to fix it!

comment:2 Changed 12 years ago by Andy Buckley

Milestone: Version 1.2Version 1.1.2
Status: newassigned

Should be fixed now, but maybe not consistently... my job to check that it's all okay.

comment:3 Changed 12 years ago by Andy Buckley

Resolution: fixed
Status: assignedclosed

This is now fixed: the m4 pkgcheck macros treated --with-boost and --with-boost-incdir inconsistently. Also fixed for the bootstrap script (in dev mode --- rehack needed on 1.1.2 release since dev -> stable)

comment:4 Changed 12 years ago by jmonk

Cc: hoeth added

This is still causing me a problem in the plugindemo. Is there any reason I can't add -I$(BOOSTINCPATH) to the rule for the pluginlib?

comment:5 Changed 12 years ago by Andy Buckley

No, that should be fine: it's causing a problem in plugindemo because the build there isn't using normal automake rules (partially because of libtool no making the .so/.dylib before installation, partially because it's useful for "casual" users to have a generic Make rule rather than an AM-specific one).

In fact, any build flags that are normally passed by automake as part of AM_CPPFLAGS, AM_LDFLAGS or AM_CXXFLAGS should probably be explicitly given in that command... although there is also some value in keeping it simple.

Note: See TracTickets for help on using tickets.