I agree that boost should be found via cmake or pkgconfig rather than a special ROS tool.  For now I have instructed the users of my ros-osx branch to add this to their bashrc: 

export CPLUS_INCLUDE_PATH="/usr/local/include:$CPLUS_INCLUDE_PATH"

The problem is odd because when you use isysroot=/Developer/SDKs/MacOSX10.7.sdk or similar you are chaining where the compiler looks for headers and libraries by default (/).  To mitigate this there is a symlink from /usr/local/lib to /Developer/SDKs/MacOSX10.7.sdk/usr/local/lib, but what gets me is that there is no corresponding link to /usr/local/include...  Maybe someone with more OS X development experience could explain that.  

I think my solution is fine for now, but won't be necessary if every package found the header path for each of it's deps automatically, i.e. there is no good reason, other than convenience, for having /usr/local/include in the include paths by default.  

For example, I added the tinyxml ROS package as a rosdep in two packages that used tinyxml because they couldn't find the headers or libraries located in /usr/local otherwise (tinyxml has no Findtinyxml.cmake or similar).  (The tinyxml ROS pkg just contains the tinyxml header and has appropriate exports in the manifest.xml).

--

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
William Woodall
Graduate Software Engineering
Auburn University
w@auburn.edu
wjwwood@gmail.com
williamjwoodall.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



On Wed, Sep 7, 2011 at 10:36 AM, Brian Gerkey <gerkey@willowgarage.com> wrote:
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.
_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users