search

scpeters-test / sdformat

Simulation Description Format (SDF) parser and description files.
http://sdformat.org
Other
1 stars 0 forks source link

Make SDFormat lighter weight, by removing boost. #34

Open scpeters-test opened 10 years ago

scpeters-test commented 10 years ago

Original report (archived issue) by John Hsu (Bitbucket: hsu, GitHub: hsu).

Strip boost dependency. This will make it more portable.

Example of what we need from boost can be found in this directory

scpeters-test commented 10 years ago

Original comment by Steve Peters (Bitbucket: Steven Peters).

You don't like shared pointers?

scpeters-test commented 10 years ago

Original comment by John Hsu (Bitbucket: hsu, GitHub: hsu).

scpeters-test commented 10 years ago

Original comment by Steve Peters (Bitbucket: Steven Peters).

I can think of two different goals here:

  1. Make it so sdformat doesn't depend on boost at all. You've provided a link to Erwin's stripped down version of boost as an idea for how to retain the functionality.

  2. Use boost internally, but make it so downstream software that uses sdformat doesn't have to depend on boost, so that there are no boost references in any header files for example. This way if they have the sdformat deb installed, then they don't need to compile against bullet.

Which one are you proposing?

scpeters-test commented 7 years ago

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

scpeters-test commented 7 years ago

Original comment by clalancette (Bitbucket: clalancette, GitHub: clalancette).

So I've been going through this problem. Here's what I know about boost use within SDFormat:

  1. Boost regex is used
  2. Boost lexical_casts are used
  3. Boost filesystem is used
  4. Boost::Any is used
  5. Boost is used by the internal urdfdom copy

A few days ago I opened a pull request to get rid of the boost regex dependency (1). Once that is in, I have a pending pull request to remove most of the uses of lexical_cast (2). That leaves the harder ones. We can take care of (3) by removing the internal urdfdom implementation, which we plan to do, but will need some work as the API has changed. Taking care of (4) means changing the external API, which we will have to do by deprecating the current Boost::Any API, adding a new API to replace it, waiting a release cycle, and then removing it completely. Finally, taking care of (5) means that we have to have our own cross-platform filesystem implementations, which we can do, but will take some work.

scpeters-test commented 7 years ago

Original comment by clalancette (Bitbucket: clalancette, GitHub: clalancette).