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

[sdformat13] new port #31280

Merged
merged 3 commits into from
Aug 25, 2023
Merged

[sdformat13] new port #31280

merged 3 commits into from
Aug 25, 2023

Conversation

talregev
Copy link
Contributor

@talregev talregev commented May 5, 2023

Add sdformat13 port:

  • Changes comply with the maintainer guide
  • The name of the port matches an existing name for this component on https://repology.org/ if possible, and/or is strongly associated with that component on search engines.
  • Optional dependencies are resolved in exactly one way. For example, if the component is built with CMake, all find_package calls are REQUIRED, are satisfied by vcpkg.json's declared dependencies, or disabled with CMAKE_DISABLE_FIND_PACKAGE_Xxx
  • The versioning scheme in vcpkg.json matches what upstream says.
  • The license declaration in vcpkg.json matches what upstream says.
  • The installed as the "copyright" file matches what upstream says.
  • The source code of the component installed comes from an authoritative source.
  • The generated "usage text" is accurate. See adding-usage for context.
  • The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
  • Only one version is in the new port's versions file.
  • Only one version is added to each modified port's versions file.

@talregev
Copy link
Contributor Author

talregev commented May 5, 2023

I got this error:

CMake Error: install(EXPORT "sdformat13" ...) includes target "sdformat13" which requires target "using_parser_urdf" that is not in any export set.
CMake Error in src/CMakeLists.txt:
  export called with target "sdformat13" which requires target
  "using_parser_urdf" that is not in any export set.

@talregev
Copy link
Contributor Author

talregev commented May 5, 2023

logs:
sdformat13.zip

@Adela0814 Adela0814 added the category:new-port The issue is requesting a new library to be added; consider making a PR! label May 6, 2023
@Adela0814
Copy link
Contributor

Note: I will be converting your PR to draft status. If you fixed the issue with CI, please reactivate it.

@Adela0814 Adela0814 marked this pull request as draft May 6, 2023 10:33
@talregev
Copy link
Contributor Author

talregev commented May 6, 2023

@Adela0814 Can you explain why this error is happening? Is it come from vcpkg?
I try to look on it on the internet, and I didn't any export on the sdformat repo cod side.
vcpkg make export?

@talregev
Copy link
Contributor Author

talregev commented May 7, 2023

@autoantwort @dg0yt @traversaro
Can you help?

@dg0yt
Copy link
Contributor

dg0yt commented May 7, 2023

Grep for using_parser_urdf in the source code and see if it either can be added to the export set or recconstructed in the installed config file?

@traversaro
Copy link
Contributor

I think it is a bug upstream in vcpkg in the case BUILD_SHARED_LIBS is set to OFF. In https://github.com/gazebosim/sdformat/blob/38f6435e095b5d82984aa26bbeac40ce08e34229/src/CMakeLists.txt#L118 the sdformat13 links as PRIVATE the using_parser_urdf INTERFACE target. As long as BUILD_SHARED_LIBS is set to ON, everything works fine as private linked libraries do not need to be found when find_package(sdformat13) is called, but if BUILD_SHARED_LIBS is set to OFF, then using_parser_urdf needs to be found when find_package(sdformat13) is called, and hence it should be installed. I guess the error went unnoticed upstream as there are not a lot of users for the case when BUILD_SHARED_LIBS is set to OFF.

@talregev
Copy link
Contributor Author

talregev commented May 7, 2023

Grep for using_parser_urdf in the source code and see if it either can be added to the export set or recconstructed in the installed config file?

It added on the cmake:
https://github.com/gazebosim/sdformat/blob/sdformat13_13.0.0/src/CMakeLists.txt#L26

@talregev
Copy link
Contributor Author

talregev commented May 7, 2023

I think it is a bug upstream in vcpkg in the case BUILD_SHARED_LIBS is set to OFF

It by design. Can we compile it only with static?
Can we patch it, or make gazebo upstream changes?

@dg0yt
Copy link
Contributor

dg0yt commented May 7, 2023

I think it is a bug upstream in vcpkg in the case BUILD_SHARED_LIBS is set to OFF

To be clear, AFAIU it is a bug in upstream which becomes visible in vcpkg's static triplets.

It by design. Can we compile it only with static? Can we patch it, or make gazebo upstream changes?

I don't see how this is "by design". It should be fixed upstream, and the same patch can be applied in the vcpkg port for the current release.

@talregev
Copy link
Contributor Author

talregev commented May 7, 2023

I think it is a bug upstream in vcpkg in the case BUILD_SHARED_LIBS is set to OFF

To be clear, AFAIU it is a bug in upstream which becomes visible in vcpkg's static triplets.

It by design. Can we compile it only with static? Can we patch it, or make gazebo upstream changes?

I don't see how this is "by design". It should be fixed upstream, and the same patch can be applied in the vcpkg port for the current release.

I meant it by design that vcpkg turn off the shared libs in Linux compilation.

@dg0yt
Copy link
Contributor

dg0yt commented May 7, 2023

I don't see how this is "by design". It should be fixed upstream, and the same patch can be applied in the vcpkg port for the current release.

I meant it by design that vcpkg turn off the shared libs in Linux compilation.

Oh, I don't think this is by design, but just the historic choice of the "supported triplet" x64-linux. There is also a x64-linux-dynamic "community triplet".

@talregev
Copy link
Contributor Author

talregev commented May 7, 2023

@traversaro But it also fail on windows that have shared libs on. Why?

@dg0yt
Copy link
Contributor

dg0yt commented May 7, 2023

The new gz port are still not mature.

Make Error at D:/installed/x64-windows/share/cmake/gz-cmake3/cmake3/GzConfigureBuild.cmake:73 (message):
  -- BUILD ERRORS: These must be resolved before compiling.
Call Stack (most recent call first):
  CMakeLists.txt:157 (gz_configure_build)


CMake Error at D:/installed/x64-windows/share/cmake/gz-cmake3/cmake3/GzConfigureBuild.cmake:75 (message):
  -- 	Couldn't find the urdfdom >= 1.0 system installation
Call Stack (most recent call first):
  CMakeLists.txt:157 (gz_configure_build)


CMake Error at D:/installed/x64-windows/share/cmake/gz-cmake3/cmake3/GzConfigureBuild.cmake:77 (message):
  -- END BUILD ERRORS

Call Stack (most recent call first):
  CMakeLists.txt:157 (gz_configure_build)


CMake Error at D:/installed/x64-windows/share/cmake/gz-cmake3/cmake3/GzConfigureBuild.cmake:82 (message):
  Errors encountered in build.  Please see BUILD ERRORS above.
Call Stack (most recent call first):
  CMakeLists.txt:157 (gz_configure_build)

@talregev
Copy link
Contributor Author

talregev commented May 7, 2023

@dg0yt Can you fix it?

@dg0yt
Copy link
Contributor

dg0yt commented May 8, 2023

I guess for Windows, urdfdom needs ros/urdfdom#169.

@talregev
Copy link
Contributor Author

talregev commented May 8, 2023

I guess for Windows, urdfdom needs ros/urdfdom#169.

ok. I will appreciate your fix.

@talregev
Copy link
Contributor Author

I guess for Windows, urdfdom needs ros/urdfdom#169.

@dg0yt windows is still fail after update urdfdom with the patch you suggested:
ros/urdfdom#169
Can you help?

@dg0yt
Copy link
Contributor

dg0yt commented May 13, 2023

-- Configuring done
CMake Error: install(EXPORT "sdformat13" ...) includes target "sdformat13" which requires target "using_parser_urdf" that is not in any export set.
CMake Error in src/CMakeLists.txt:
 export called with target "sdformat13" which requires target
 "using_parser_urdf" that is not in any export set.

The remaining build error is a bug in the project's files and unrelated to windows.
The build system uses custom (gz) functions instead of pure CMake.
Look/ask upstream.

@traversaro
Copy link
Contributor

The error is the one described in #31280 (comment) , nothing related to the use of gz_ CMake function.

@talregev
Copy link
Contributor Author

talregev commented May 13, 2023

The error is the one described in #31280 (comment) , nothing related to the use of gz_ CMake function.

@traversaro
Please create a PR in upstream, and I will make a patch from it.

@dg0yt
Copy link
Contributor

dg0yt commented May 13, 2023

The error is the one described in #31280 (comment) , nothing related to the use of gz_ CMake function.

using_parser_urdf is an interface target created in sdformat13 src/CMakeLists.txt, and linked to the main library target. This is the standard CMake stuff.
However, the export of CMake config is hidden in gz functions. This export would need to handle the interface target as well.

@talregev
Copy link
Contributor Author

The error is the one described in #31280 (comment) , nothing related to the use of gz_ CMake function.

using_parser_urdf is an interface target created in sdformat13 src/CMakeLists.txt, and linked to the main library target. This is the standard CMake stuff. However, the export of CMake config is hidden in gz functions. This export would need to handle the interface target as well.

Do you know how to solve it?
Can we make a patch for it?

@dg0yt
Copy link
Contributor

dg0yt commented May 13, 2023

Do you know how to solve it?

That's the point I'm trying to make: I know how to use CMake. But once projects start to use their own language of macros and functions, it becomes tedious to find out where it breaks and how to fix it. We don't even have a CMake call stack to start from because the error shows too late.

@traversaro
Copy link
Contributor

The error is the one described in #31280 (comment) , nothing related to the use of gz_ CMake function.

using_parser_urdf is an interface target created in sdformat13 src/CMakeLists.txt, and linked to the main library target. This is the standard CMake stuff. However, the export of CMake config is hidden in gz functions. This export would need to handle the interface target as well.

Ahh, sorry I misunderstdood, that's totally correct.

@traversaro
Please create a PR in upstream, and I will make a patch from it.

I am happy to give you the hints to understand how to fix it. To be honest I am not interest at the moment in building sdformat13 as part of vcpkg and in static mode, so I prefer not to prepare the PR and submit it.

The sdformat13 library is created in https://github.com/gazebosim/gz-cmake/blob/gz-cmake3_3.1.0/cmake/GzUtils.cmake#L1540 and installed in https://github.com/gazebosim/gz-cmake/blob/gz-cmake3_3.1.0/cmake/GzUtils.cmake#L1611 , so the EXPORT used for it is sdformat13 . The target installed with that export are installed in https://github.com/gazebosim/gz-cmake/blob/88e7dc5f727e2270f206f19f558ab8f7fb5b8df1/cmake/GzPackaging.cmake#L372 . So a simple workaround is to just install the using_parser_urdf with the sdformat13 export, close to where using_parser_urdf library is defined with add_library.

@dg0yt
Copy link
Contributor

dg0yt commented May 13, 2023

Okay, I managed to add the install line. I will send a PR for this port to @talregev, adding a few more changes.

@Adela0814
Copy link
Contributor

Note: I will be converting your PR to draft status. When you respond, please revert to "ready for review". That way, I can be aware that you've responded since you can't modify the tags.

@Adela0814 Adela0814 marked this pull request as draft July 25, 2023 09:00
@talregev talregev requested a review from Adela0814 August 16, 2023 21:59
@talregev talregev marked this pull request as ready for review August 16, 2023 21:59
@Adela0814
Copy link
Contributor

@talregev I'm a bit confused, does sdformat require so many different versions of ports(sdformat6, sdformat9, sdformat10, sdformat13)? Instead of updating existing ports?

@talregev
Copy link
Contributor Author

talregev commented Aug 17, 2023

@talregev I'm a bit confused, does sdformat require so many different versions of ports(sdformat6, sdformat9, sdformat10, sdformat13)? Instead of updating existing ports?

we already have this discussions on gz-ports:
#28656
#28656 (review)

The conclusion was to add new gz-port while maintain all the old other port with their version number.

@talregev
Copy link
Contributor Author

talregev commented Aug 17, 2023

The error is the one described in #31280 (comment) , nothing related to the use of gz_ CMake function.

using_parser_urdf is an interface target created in sdformat13 src/CMakeLists.txt, and linked to the main library target. This is the standard CMake stuff. However, the export of CMake config is hidden in gz functions. This export would need to handle the interface target as well.

Ahh, sorry I misunderstdood, that's totally correct.

@traversaro
Please create a PR in upstream, and I will make a patch from it.

I am happy to give you the hints to understand how to fix it. To be honest I am not interest at the moment in building sdformat13 as part of vcpkg and in static mode, so I prefer not to prepare the PR and submit it.

The sdformat13 library is created in https://github.com/gazebosim/gz-cmake/blob/gz-cmake3_3.1.0/cmake/GzUtils.cmake#L1540 and installed in https://github.com/gazebosim/gz-cmake/blob/gz-cmake3_3.1.0/cmake/GzUtils.cmake#L1611 , so the EXPORT used for it is sdformat13 . The target installed with that export are installed in https://github.com/gazebosim/gz-cmake/blob/88e7dc5f727e2270f206f19f558ab8f7fb5b8df1/cmake/GzPackaging.cmake#L372 . So a simple workaround is to just install the using_parser_urdf with the sdformat13 export, close to where using_parser_urdf library is defined with add_library.

@traversaro Will you consider the next version of sdformat will support vcpkg in sperate static and dynamic mode?

@talregev
Copy link
Contributor Author

@Adela0814 adding unofficial- as a prefix, create to build failure:

CMake Error: install(EXPORT "sdformat13" ...) includes target "sdformat13" which requires target "using_parser_urdf" that is not in any export set.
CMake Error in src/CMakeLists.txt:
  export called with target "sdformat13" which requires target
  "using_parser_urdf" that is not in any export set.

Please read comments here:
#31280 (comment)

I want to revert this change.

@traversaro
Copy link
Contributor

@traversaro Will you consider the next version of sdformat will support vcpkg in sperate static and dynamic mode?

I am not a mantainer of sdformat, but I guess that if you submit a PR based on #31280 (comment) explaining in which case it is useful I guess the mantainers would be happy to review it.

@talregev
Copy link
Contributor Author

talregev commented Aug 17, 2023

@traversaro Will you consider the next version of sdformat will support vcpkg in sperate static and dynamic mode?

I am not a mantainer of sdformat, but I guess that if you submit a PR based on #31280 (comment) explaining in which case it is useful I guess the mantainers would be happy to review it.

If I knew how to solve it, I was create a PR and a patch. I am lacking the knowledge how to do it.
It solve only for linux and not for windows. I am not sure why.

@traversaro
Copy link
Contributor

@traversaro Will you consider the next version of sdformat will support vcpkg in sperate static and dynamic mode?

I am not a mantainer of sdformat, but I guess that if you submit a PR based on #31280 (comment) explaining in which case it is useful I guess the mantainers would be happy to review it.

If I knew how to solve it, I was create a PR and a patch. I am lacking the knowledge how to do it. It solve only for linux and not for windows. I am not sure why.

If you open an (even incomplete) PR on sdformat it may be easier to iterate on your solution and provide you suggestions.

@talregev
Copy link
Contributor Author

talregev commented Aug 17, 2023

@traversaro Will you consider the next version of sdformat will support vcpkg in sperate static and dynamic mode?

I am not a mantainer of sdformat, but I guess that if you submit a PR based on #31280 (comment) explaining in which case it is useful I guess the mantainers would be happy to review it.

If I knew how to solve it, I was create a PR and a patch. I am lacking the knowledge how to do it. It solve only for linux and not for windows. I am not sure why.

If you open an (even incomplete) PR on sdformat it may be easier to iterate on your solution and provide you suggestions.

I will copy the solution from here, and I will happy for your guidance and suggestion and test it
both on linux and windows. (also for mac with the vcpkg ci).

@talregev
Copy link
Contributor Author

@Adela0814 adding unofficial- as a prefix, create to build failure:

CMake Error: install(EXPORT "sdformat13" ...) includes target "sdformat13" which requires target "using_parser_urdf" that is not in any export set.
CMake Error in src/CMakeLists.txt:
  export called with target "sdformat13" which requires target
  "using_parser_urdf" that is not in any export set.

Please read comments here: #31280 (comment)

I want to revert this change.

@Adela0814 I will happy to hear your comment about the build fail.

talregev and others added 3 commits August 22, 2023 23:53
* Fix cmake config export

* Cleanup

* Add usage

* Update versions
@talregev
Copy link
Contributor Author

@Adela0814 It now compile also on windows.
Please review it again.

@Adela0814 Adela0814 added the info:reviewed Pull Request changes follow basic guidelines label Aug 24, 2023
@talregev
Copy link
Contributor Author

@Adela0814 Thank you for your approve.
I see this PR didn't get in the previous batch.
Are we waiting for more review?

@dan-shaw dan-shaw merged commit d71315b into microsoft:master Aug 25, 2023
@talregev talregev deleted the TalR/sdformat13 branch August 25, 2023 19:23
@talregev
Copy link
Contributor Author

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category:new-port The issue is requesting a new library to be added; consider making a PR! info:reviewed Pull Request changes follow basic guidelines
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants