Merge sdf13 ➡️ main

[quarkytale]

➡️ Forward port

Port sdf13 to main

Branch comparison: main...sdf13

Note to maintainers: Remember to Merge with commit (not squash-merge or rebase)

Need help with resolving sdf/embedSdf.py, seems like the file was first added to main and backported to sdf13, but still there are some changes in functions, see

• https://github.com/gazebosim/sdformat/blame/sdf13/sdf/embedSdf.py
• https://github.com/gazebosim/sdformat/blame/main/sdf/embedSdf.py
  for comparison. Currently, this PR has the main version.

CC: @jasmeet0915

[scpeters]

need to update the target branch to main

[scpeters]

there are linking errors in CI

[scpeters]

these RUBY changes should not be merged forward

[quarkytale]

Tried it out, please check if it makes sense

[codecov]

Codecov Report

Merging #1297 (390834f) into main (446d691) will increase coverage by 0.39%.
The diff coverage is 94.80%.

❗ Current head 390834f differs from pull request most recent head 91b7265. Consider uploading reports for the commit 91b7265 to get more accurate results

@@            Coverage Diff             @@
##             main    #1297      +/-   ##
==========================================
+ Coverage   87.21%   87.60%   +0.39%     
==========================================
  Files         126      128       +2     
  Lines       16304    16830     +526     
==========================================
+ Hits        14219    14744     +525     
- Misses       2085     2086       +1     

Impacted Files	Coverage Δ
include/sdf/Plugin.hh	93.75% <ø> (ø)
python/src/sdf/pyProjector.cc	52.72% <52.72%> (ø)
python/src/sdf/pyLink.cc	58.25% <57.14%> (-0.18%)	⬇️
src/parser.cc	86.80% <83.72%> (-0.19%)	⬇️
src/Element.cc	96.21% <89.24%> (+0.39%)	⬆️
src/Collision.cc	97.43% <92.30%> (+0.17%)	⬆️
include/sdf/Element.hh	97.67% <95.23%> (-2.33%)	⬇️
src/Material.cc	95.76% <95.34%> (+0.39%)	⬆️
src/Projector.cc	95.68% <95.68%> (ø)
src/parser_urdf.cc	88.14% <96.36%> (+0.34%)	⬆️
... and 30 more

... and 3 files with indirect coverage changes

[scpeters]

do you mind squashing 6a8b3d1 and b41123b together?

[quarkytale]

Squashed them to the main merge commit only

[quarkytale]

DCO is failing for older commits, is it okay to set it pass manually or should I add my signature on previous commits?

[scpeters]

DCO is failing for older commits, is it okay to set it pass manually or should I add my signature on previous commits?

I reviewed the DCO issues and set it to pass manually because it was an issue with email matching

[scpeters]

I think this OUTPUT_FILE line needs to be removed, since we are passing --output-file. I think this is causing the windows build failure

[scpeters]

I think you removed the wrong line in your force-push to 5fbe349 (comparison https://github.com/gazebosim/sdformat/compare/25d793e8149cffb8d5c05b526a31fa030943e952..5fbe349793af470b359972c2d0e4e9be5435224d)

I think the --output-file "${PROJECT_BINARY_DIR}/src/EmbeddedSdf.cc" line should remain but the OUTPUT_FILE "${PROJECT_BINARY_DIR}/src/EmbeddedSdf.cc" line should be removed

[quarkytale]

My bad, should be correct now

[scpeters]

Yes, that line looks good now!

[scpeters]

There is still something wrong in the Windows build with lots of tests failing with an error message about converting between versions:

Unable to convert from SDF version 1.6 to 1.10
SDF does not have a version.

This seems related to the embed script behavior that was changed in #1240. I also see some compiler warnings from the generated EmbeddedSdf.cc file:

C:\J\workspace\sdformat-pr-win\ws\build\sdformat14\src\EmbeddedSdf.cc(287,1): warning C4129: 'c': unrecognized character escape sequence [C:\J\workspace\sdformat-pr-win\ws\build\sdformat14\src\sdformat14.vcxproj]

C:\J\workspace\sdformat-pr-win\ws\build\sdformat14\src\EmbeddedSdf.cc(523,1): warning C4129: 'c': unrecognized character escape sequence [C:\J\workspace\sdformat-pr-win\ws\build\sdformat14\src\sdformat14.vcxproj]
...

I copied this file from the Jenkins file and see the following on the mentioned lines:

"1.10\camera.sdf",

and

"1.10\capsule_shape.sdf",

This looks like a problem with the path separator. Glancing through the changes in #1240, I see that the get_map_content method used PurePosixPath to force use of / path separators, but that line is not present in the generate_map_content method. I think we didn't notice it in #1240 because that script isn't used in Windows CI on the sdf13 branch

[quarkytale]

Thanks for taking a look! Should I work on adding/reverting that PR or needs to be discussed during the weekly?

[scpeters]

Thanks for taking a look! Should I work on adding/reverting that PR or needs to be discussed during the weekly?

I've attempted a fix in 91b7265

[scpeters]

Thanks for taking a look! Should I work on adding/reverting that PR or needs to be discussed during the weekly?

I've attempted a fix in 91b7265

seems to be working. I'll defer to @azeey or @mjcarroll for a review on 91b7265

[azeey]

Thanks for taking a look! Should I work on adding/reverting that PR or needs to be discussed during the weekly?

I've attempted a fix in 91b7265

seems to be working. I'll defer to @azeey or @mjcarroll for a review on 91b7265

Looks good to me. @mjcarroll was there a reason for removing the PurePosixPath in #1240?

[mjcarroll]

@mjcarroll was there a reason for removing the PurePosixPath in #1240?

Not for any reason that I recall at this point.