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 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, 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@lists.ros.org >> [mailto:ros-users-bounces@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, 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@lists.ros.org >> [mailto:ros-users-bounces@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 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@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@telematik-zentrum.de >> >> Web: http://www.telematik-zentrum.de >> >> >> >> _______________________________________________ >> >> ros-users mailing list >> >> ros-users@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@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@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@lists.ros.org >> http://lists.ros.org/mailman/listinfo/ros-users >> > > > > -- > William Woodall > ROS Development Team > william@osrfoundation.org > http://williamjwoodall.com/ > > _______________________________________________ > ros-users mailing list > ros-users@lists.ros.org > http://lists.ros.org/mailman/listinfo/ros-users > _______________________________________________ ros-users mailing list ros-users@lists.ros.org http://lists.ros.org/mailman/listinfo/ros-users