On Mon, Sep 5, 2011 at 3:34 PM, William Woodall <
wjwwood@gmail.com> wrote:
> I need to add -I/usr/local/include to the c++ arguments when compiling
> something with boost (but more generally it should be a system default
> include). How should that be accomplished?
>
> Should the rosboost-cfg --include_dirs return that? (currently it doesn't
> because it detects the Homebrew boost as being "system installed" and
> returns "")
>
> https://code.ros.org/trac/ros/browser/stacks/ros/tags/ros-1.6.2/tools/rosboost_cfg/src/rosboost_cfg/rosboost_cfg.py#L250
> This implys that the larger issue should be fixed by each individual library
> with headers in /usr/local/include
>
> Should "/usr/local/include" be added to the CPLUS_INCLUDE_PATH in something
> like .bashrc?
hi William,
I can see the argument for modifying rosboost-cfg to add
-I/usr/local/include on your system, on the basis that rosboost-cfg's
"is it a system install?" heuristic is wrong in this case. For better
generality, we could probably make rosboost-cfg smarter by, for
example, having it query the compiler's default search paths instead
of assuming that '/usr/' and '/usr/local/' are system install
locations for everyone.
But I worry that you'd end up covering a problem finding something
else that gets installed to /usr/local. How did boost get there for
you? In general, if you're installing software to a location that
your compiler/linker won't search by default, then it's incumbent on
you to tell the compiler/linker where to look, usually by modifying
your environment (CPATH, LIBRARY_PATH,
LD_LIBRARY_PATH/DYLD_LIBRARY_PATH/DYLD_FALLBACK_LIBRARY_PATH).
And instead of improving rosboost-cfg, I'd prefer to get rid of it.
We really ought to be able to find and use boost without maintaining
our own configuration tool.
brian.
(text/plain)