[ros-users] ROS usability -> boost

Thu Feb 20 23:13:17 UTC 2014

Another potential pitfall of including your own copy/version/part of
an external library, especially a popular one like Boost, is that your
users can have trouble combining your code with the "official" version
of the library.  Unless you modify the internalized code to
re-namespace, mangle, or otherwise hide symbols, you'll get
linker-time collisions (or worse, run-time crashes).

So, while it can be pragmatic to pull in a troublesome external
dependency in some situations, it's not something that I would do
without serious consideration of the consequences.

brian.

On Thu, Feb 20, 2014 at 10:23 AM, William Woodall
<william at osrfoundation.org> wrote:
> I've actually suggested internalizing things in the past, but it should be
> recognized that it is a trade-off. By internalizing the software you are
> taking on some support role for that software. Additionally, since you are
> not forced to update the software by your package manager, you never take on
> bug fixes or security fixes, which in turn becomes part of the additional
> maintenance role you take on.
>
> Also if your internalized thing is not header only, it increases the size of
> your binary and your compile time compared to depending on a shared library.
>
> It also can affect portability. If you depend on boost, then on exotic
> machines the system provided boost will presumably be patched to work on it,
> whereas your internalized copy will need those patches applied separately.
>
> I still think internalizing dependencies is a good a idea in some cases, and
> excluding them where ever possible is better. But it is not a clear
> advantage in all scenarios.
>
>
> On Thu, Feb 20, 2014 at 9:03 AM, <rdean at gdrs.com> wrote:
>>
>> The advantage of putting a 2 after the name is a new minimum set of
>> requirements, such as Ubuntu 14.0x maybe. Hopefully not 16.0x >.>
>>
>>
>>
>> Another aspect that I have found is common with my various RCTA
>> collaborators is when selecting a dependency, pulling it into the build
>> tree. Minimize external dependencies of the core. I believe this is what the
>> roscpp authors did with xmlrpc as well, but there seems to be some slipping
>> away from this (see Ryan Gariepy's new thread on usability).
>>
>>
>>
>> For example, I have an opensource subdirectory which has a version of the
>> json-c library imported into a namespace to remove link time errors with
>> system defaults. My next step, for example, is to extract out boost::chrono
>> from boost itself and build it with the tree. Boost::chrono currently
>> supports nanosecond timer resolution where std::chrono does not. By doing
>> this I can revert back to using the default Ubuntu 12.04 antique version of
>> boost.
>>
>>
>>
>> A good idea may also be to start a "best practices of software
>> engineering" tutorial or wiki page. There could for example be an article on
>> boost::mpl and its plusses/minuses. From my experience by the time you
>> figure out how to do it with mpl, it would have been faster to just write a
>> new method which would compile faster (see previous comments about
>> #include's)
>>
>>
>>
>>
>>
>> From: ros-users-bounces at lists.ros.org
>> [mailto:ros-users-bounces at lists.ros.org] On Behalf Of Brian Gerkey
>> Sent: Thursday, February 20, 2014 11:44 AM
>> To: User discussions
>> Subject: Re: [ros-users] ROS usability -> boost
>>
>>
>>
>> That's great feedback. We were just discussing this issue the other day
>> and came to the conclusion that we should start new projects (e.g., ROS 2)
>> using what's now in the standard, and only pull in boost if it becomes
>> really necessary. The cost of this approach is that you need a reasonably
>> modern compiler, but that seems like a good trafeoff to make.
>>
>> brian.
>>
>> On Feb 20, 2014 8:01 AM, <rdean at gdrs.com> wrote:
>>
>> On the boost topic, I have been a boost fan for many years... until having
>> to support multiple versions.  Recently I changed all our core to use C++0x
>> equivalents which fixed the dependency issues, and surprisingly compiles 30%
>> faster.  (basically boost #include's a massive number of headers, while gcc
>> equivalents do not)
>>
>> This is an important point for moving forwards with ROS simplicity in
>> addition to API and tutorial type usability. Make use of what the compiler
>> provides while avoiding "tricks" in the language (some template solutions
>> out on the web are cool, but eat up compile time and complexity.
>> *cough*mpl*cough*). Even something as common as Boost has potentially nasty
>> dependency and code complexity issues. Maybe retrofitting roscpp is a poor
>> use of resources at this time, but moving forwards with new code or ROS2.0
>> it makes sense.
>>
>> -----Original Message-----
>> From: ros-users-bounces at lists.ros.org
>> [mailto:ros-users-bounces at lists.ros.org] On Behalf Of kamicc olo
>> Sent: Thursday, February 20, 2014 8:56 AM
>> To: User discussions
>> Subject: Re: [ros-users] ROS usability
>>
>> Been facing an issue with SSE and ARM for some time either. Not mentioning
>> libboost...
>>
>> On 2/20/14, Arkapravo Bhaumik <arkapravobhaumik at gmail.com> wrote:
>> > Agree on the redundancy of packages (read xkcd zindabad) and the boost
>> > issues ! Have faced serious boost issues.
>> >
>> >
>> > On 20 February 2014 18:36, Michael Fritscher <
>> > michael.fritscher at telematik-zentrum.de> wrote:
>> >
>> >> Hallo everybody,
>> >>
>> >> just my 2 cents:
>> >>
>> >> In my oppinion, the ROS core is fairly well documented and quite
>> >> useable
>> >> -
>> >> both for beginners and advanced users. The problem are in my oppinion
>> >> many of the packages. Most of the packages are more or less drivers
>> >> for robots or middleware things. But even e.g. on the usb camera side
>> >> there are at least 5 different drivers (see
>> >> http://www.iheartrobotics.com/
>> >> 2010/05/testing-ros-usb-camera-drivers.html and
>> >> http://pharos.ece.utexas.edu/wiki/index.php/How_to_Use_a_
>> >> Webcam_in_ROS_with_the_gscam_Package ) - why the heck we do need at
>> >> least
>> >> 5 drivers for a simple thing like capturing webcam pictures?! I know
>> >> that there are different requirements, but forking isn't always the
>> >> best solution...
>> >>
>> >> Additionally, many plugins aren't that usable. Are little example are
>> >> localization using 1 or 2 video cameras. viso2_ros doesn't need sse2,
>> >> which is a no-go for ARM-cpus which are getting more and more
>> >> popular.
>> >> PTAM is at least compiling, but it even fail to correctly display the
>> >> video image (both on arm and on a normal x64 laptop). Sometimes it
>> >> remembers me about https://xkcd.com/927/ ...
>> >>
>> >> Another problem is in my oppinion the library-hell problem. ROS
>> >> packages are tightly tied with specific library version (e.g.
>> >> libboost) which
>> >> (roughly) exists only on one specific distro-version. This makes it
>> >> almost inpossible to use binary versions of ros on another distros.
>> >> Perhaps this can be solved that the binary packages depend on e.g.
>> >> "libboost-1.42 | roslibboost-groovy" - so either the distro-version
>> >> or a ros-own version can be used.
>> >>
>> >> Best regards,
>> >> Michael Fritscher
>> >>
>> >> --
>> >> ZfT - Zentrum für Telematik e.V.
>> >> Michael Fritscher
>> >> Allesgrundweg 12
>> >> 97218 Gerbrunn
>> >> Tel:  +49 (931) 3 29 29 54 - 21
>> >> Email: michael.fritscher at telematik-zentrum.de
>> >> Web: http://www.telematik-zentrum.de
>> >>
>> >> _______________________________________________
>> >> ros-users mailing list
>> >> ros-users at lists.ros.org
>> >> http://lists.ros.org/mailman/listinfo/ros-users
>> >>
>> >>
>> >
>> >
>> > --
>> > *Arkapravo Bhaumik*
>> >
>> >
>> > http://mobotica.blogspot.in/p/head.html
>> >
>> _______________________________________________
>> ros-users mailing list
>> ros-users at lists.ros.org
>> http://lists.ros.org/mailman/listinfo/ros-users
>>
>> -------------------------------------------------------
>> This is an e-mail from General Dynamics Robotic Systems. It is for the
>> intended recipient only and may contain confidential and privileged
>> information. No one else may read, print, store, copy, forward or act in
>> reliance on it or its attachments. If you are not the intended recipient,
>> please return this message to the sender and delete the message and any
>> attachments from your computer. Your cooperation is appreciated.
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at lists.ros.org
>> http://lists.ros.org/mailman/listinfo/ros-users
>>
>> ------------------------------------------------------
>>
>> This is an e-mail from General Dynamics Robotic Systems. It is for the
>> intended recipient only and may contain confidential and privileged
>> information. No one else may read, print, store, copy, forward or act in
>> reliance on it or its attachments. If you are not the intended recipient,
>> please return this message to the sender and delete the message and any
>> attachments from your computer. Your cooperation is appreciated.
>>
>>
>> _______________________________________________
>> ros-users mailing list
>> ros-users at lists.ros.org
>> http://lists.ros.org/mailman/listinfo/ros-users
>>
>
>
>
> --
> William Woodall
> ROS Development Team
> william at osrfoundation.org
> http://williamjwoodall.com/
>
> _______________________________________________
> ros-users mailing list
> ros-users at lists.ros.org
> http://lists.ros.org/mailman/listinfo/ros-users
>