Just as a note of early warning,
The OSX clang++ compiler does not seem to respect the $LIBRARY_PATH
environment variable (this appears to be well documented in internet
complaints). Hopefully this will be fixed in the future, but I do expect
that in the next version of OSX in a year and a half, clang++ will become
the default OSX compiler, so it might be worth looking into upcoming
compatibility issues.
--Nick
On Wed, Sep 7, 2011 at 4:48 PM, William Woodall <
wjwwood@gmail.com> wrote:
> 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
>>
>
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
(text/plain)