Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch from TinyXML to TinyXML2 - rebase #178

Closed
wants to merge 8 commits into from

Conversation

SMillerDev
Copy link

Continues the work in #99

I know nothing about urdfdom, but with these changes the work in that PR compiles again

Dmitry Rozhkov and others added 2 commits January 17, 2023 10:15
The library TinyXML is considered to be unmaintained and
since all future development is focused on TinyXML2 this
patch updates urdfdom to use TinyXML2.

Signed-off-by: Dmitry Rozhkov <[email protected]>
Copy link
Contributor

@clalancette clalancette left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In short, we can't do things exactly like this. There are too many downstream projects that might depend on the TinyXML APIs.

Instead, what we should do is to add TinyXML2 APIs alongside the TinyXML ones, and make the TinyXML ones as deprecated. Once that is done, and has been released, we can then consider removing the TinyXML APIs.

Does that make sense?

@SMillerDev
Copy link
Author

How do you feel about leaving it up to the packager. Essentially cmake would decide what to enable

@scpeters
Copy link
Contributor

How do you feel about leaving it up to the packager. Essentially cmake would decide what to enable

Relevant context here is that homebrew-core would like to remove the tinyxml formula. I'm guessing that @clalancette would be open to adding support for tinyxml2 and a cmake option that disables support for tinyxml

urdf_parser/src/world.cpp Outdated Show resolved Hide resolved
@clalancette
Copy link
Contributor

Relevant context here is that homebrew-core would like to remove the tinyxml formula. I'm guessing that @clalancette would be open to adding support for tinyxml2 and a cmake option that disables support for tinyxml

Yes, that would be OK with me. Though I would say that we should have the default be that both TinyXML and TinyXML2 APIs are available, with a CMake option that explicitly disables the TinyXML ones. That is most consistent with how we generally tick-tock APIs.

That said, @scpeters is the maintainer here so I'll defer final approval to his judgement.

Require tinyxml2 and allow tinyxml support to be disabled.

Signed-off-by: Steve Peters <[email protected]>
URDFDOM_DLLAPI bool parseCamera(Camera&, tinyxml2::XMLElement*);
URDFDOM_DLLAPI bool parseRay(Ray&, tinyxml2::XMLElement*);
URDFDOM_DLLAPI bool parseSensor(Sensor&, tinyxml2::XMLElement*);
URDFDOM_DLLAPI bool parseModelState(ModelState&, tinyxml2::XMLElement*);
Copy link
Contributor

@traversaro traversaro Feb 14, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could it make sense to take the occasion and remove these functions that refer to tinyxml2 symbols from the public interface, to avoid in the future all the problems that we have now in the tinyxml --> tinyxml2 transition?

We could add bool exportURDFToString(const ModelInterface &model,, std::string xml_string) and bool exportURDFToFile(const ModelInterface &model,const std::string& path) to mirror the existing parseURDF and parseURDFFile . If downstream users need the tinyxml2::XMLDocument, they can always re-parse the string.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like to suggest the community picks this up since that seems like a decision that needs more knowledge about the tool than I as a mere packager of the tool possess.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure @SMillerDev . My comment is indeed more directed towards @scpeters and @clalancette .

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@traversaro yes, I think we could get rid of the APIs that write to a tinyxml2::XMLDocument. We'd still have the parse* methods that read from tinyxml2::Element* pointers. Do you have any suggestion for those? I guess since it's a raw pointer, we could use forward declarations and remove the include of tinyxml2.h?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Either fwd declare, or simply keep them only as private functions?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely better!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@clalancette and @sloretz what do you think of this API approach?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@scpeters I'm a little confused; it looks like 092b57c isn't on this branch. Is that meant to be?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's not on the branch at the moment as this PR is from @SMillerDev's branch. I'm just getting some feedback before pushing it

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@clalancette I just it to this branch

@SMillerDev
Copy link
Author

At least CI seems to like my last changes

Copy link
Contributor

@clalancette clalancette left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In short, I like the direction here. I've left a few pieces of feedback of things to fix.

All of that said, I'd prefer if we held off on merging this until after Iron is released (May of this year). I can forsee some possible packaging problems with this setup, and I want to make sure we aren't introducing them while we are trying to stabilize Iron.

cmake/FindTinyXML.cmake Outdated Show resolved Hide resolved
CMakeLists.txt Outdated Show resolved Hide resolved
CMakeLists.txt Outdated Show resolved Hide resolved
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need this file at all? I think that TinyXML2 typically ships with a valid, working CMake file, so this seems redundant. But I could be missing something here.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can see if we can do without it, this was taken from earlier PRs

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm guessing it was copied from the approach used for TinyXML but may not be necessary for TinyXML2

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is related to the distro(s) we are targeting, for example looking at Ubuntu LTS, 18.04, 20.04 and 22.04 do not have the tinyxml2-config.cmake (so find_package(tinyxml2) does not work out of the box):

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A problem with FindTinyXML2.cmake as provided is that it does not properly deal with multi-config generators. I want to link urdfdom and dependencies to another project and be able to build that in both Release and Debug (Visual Studio on Windows). I was able to do that only by using tinyxml2-config.cmake.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Platforms that need to support multi-config generators I guess that for sure will ship tinyxml2-config.cmake. Probably the best way to support both platforms with tinyxml2-config.cmake and platforms without is to add a find_package(tinyxml2 NO_MODULE) at the top of the FindTinyXML2.cmake , and in case the package is found, just put tinyxml2::tinyxml2 in TinyXML2_LIBRARIES.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not entirely sure what this entails, could you make a code suggestion?

CMakeLists.txt Outdated Show resolved Hide resolved
urdf_parser/src/joint.cpp Outdated Show resolved Hide resolved
urdf_parser/src/model.cpp Outdated Show resolved Hide resolved
Co-authored-by: Chris Lalancette <[email protected]>
@rserban
Copy link

rserban commented Apr 11, 2023

I suggest marking variables related to tinyxml2 as non-advanced when DISABLE_TINYXML_SUPPORT is set to 'ON'

@SMillerDev SMillerDev requested a review from clalancette May 7, 2023 11:57
@felixf4xu
Copy link
Contributor

In short, we can't do things exactly like this. There are too many downstream projects that might depend on the TinyXML APIs.

I don't quite understand this.

If a downstream project depends on TinyXML, they can still use tinyxml directly, providing linkage to tinyxml is not urdfdom's responsibility.

BTW, if you check the code of urdf (https://github.com/ros2/urdf/blob/humble/urdf/CMakeLists.txt#L9), it depends on tinyxml2 only, never worried about downstream project that needs tinyxml.

@felixf4xu
Copy link
Contributor

felixf4xu commented May 25, 2023

In this issue (ros2/ros2#987), urdfdom is the only remaining project that still use tinyxml, the concern that "many downstream projects that might depend on the TinyXML" is not very valid.

if urdfrom upgraded to tinyxml2, tinyxml might be removed out from rosdsitro completely, I guess.

Oh, I'm sorry and I realized urdfdom is a project both of ros and ros2. So I edited this comment just for anyone interested.
ros will not be maintained ros2 is the only target for new code so the comment above still makes some sense.

@ros-discourse
Copy link

This pull request has been mentioned on ROS Discourse. There might be relevant details there:

https://discourse.ros.org/t/upcoming-api-break-in-urdfdom/34750/1

@clalancette
Copy link
Contributor

@SMillerDev After talking about this with @scpeters and @sloretz , and getting some feedback from the community, I think we are going to go with the simple solution of just breaking the API. That is, we are just going to convert TinyXML APIs to TinyXML2, and do a new major version release.

I apologize for having set you on the path in this PR, which just ended up being too complicated for not enough gain. But I also want to thank you for your perseverance in getting this done. I'm going to close this in favor of #186, and continue development there.

@SMillerDev
Copy link
Author

I'm just happy it's moving really.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants