-
Notifications
You must be signed in to change notification settings - Fork 132
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
Conversation
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]>
There was a problem hiding this 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?
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 |
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*); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 .
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely better!
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
At least CI seems to like my last changes |
Signed-off-by: Steve Peters <[email protected]>
There was a problem hiding this 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/FindTinyXML2.cmake
Outdated
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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):
- https://packages.ubuntu.com/bionic/amd64/libtinyxml2-dev/filelist
- https://packages.ubuntu.com/focal/amd64/libtinyxml2-dev/filelist
- https://packages.ubuntu.com/jammy/amd64/libtinyxml2-dev/filelist
while 22.10 hastinyxml2-config.cmake
(probably because they switched from using the autotools build system to the cmake one to compile tinyxml2 itself): - https://packages.ubuntu.com/kinetic/amd64/libtinyxml2-dev/filelist
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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?
Co-authored-by: Chris Lalancette <[email protected]>
I suggest marking variables related to tinyxml2 as non-advanced when DISABLE_TINYXML_SUPPORT is set to 'ON' |
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 |
In this issue (ros2/ros2#987), if Oh, I'm sorry and I realized |
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 |
@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. |
I'm just happy it's moving really. |
Continues the work in #99
I know nothing about urdfdom, but with these changes the work in that PR compiles again