Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Switch from TinyXML to TinyXML2 - rebase #178
Changes from 2 commits
9c68be5
5ba4be4
b9aebf1
a65ae22
0bca496
092b57c
3e215fc
aca8250
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
This file was deleted.
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
(sofind_package(tinyxml2)
does not work out of the box):while 22.10 has
tinyxml2-config.cmake
(probably because they switched from using the autotools build system to the cmake one to compile tinyxml2 itself):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 withtinyxml2-config.cmake
and platforms without is to add afind_package(tinyxml2 NO_MODULE)
at the top of theFindTinyXML2.cmake
, and in case the package is found, just puttinyxml2::tinyxml2
inTinyXML2_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?
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 thetinyxml
-->tinyxml2
transition?We could add
bool exportURDFToString(const ModelInterface &model,, std::string xml_string)
andbool exportURDFToFile(const ModelInterface &model,const std::string& path)
to mirror the existingparseURDF
andparseURDFFile
. If downstream users need thetinyxml2::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 theparse*
methods that read fromtinyxml2::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 oftinyxml2.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.
@scpeters I'm a little confused; it looks like 092b57c isn't on this branch. Is that meant to be?
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