ament build fails to find solution file when cmake project name differs from package manifest name

[scpeters]

I was just attempting to build ign-math (cmake project name ignition-math4) with this package.xml file (package name ign_math) in an ament workspace on windows 10 with VS 2017. I was getting build failures expected str instance, NoneType found, that I traced to a missing solution file, which is named ignition-math4.sln. I modified the package.xml name to be ignition-math4 and then it worked.

Is this a strict requirement that the cmake project name must match the package.xml name?

[wjwwood]

Is this a strict requirement that the cmake project name must match the package.xml name?

No, but it is common practice. If you didn't use a package.xml then I think ament would have extracted the project name from CMake automatically.

I'm not sure if there is a way for us to "guess" the right solution file name each time. I guess we could do:

• extract the project name
  • but you probably can override this setting in CMake (have a different solution file name from the project name)
• look in the root build folder and assert there is only one .sln file and use that
• something else?

[dirk-thomas]

The package manifest is the only reliable source for the package name in this case. I think it must match the project name used in CMake.

• Detecting the project name based on the CMakeLists.txt will not work if the argument to project() is not a literal string.
• Asserting for a single .sln is fragile. Nothing prevent a CMake project to have other projects in the same build space (might not be nice but users usually do anything imaginable).

The question is why should the name in the manifest not match the CMake project name? If I remember correctly we had a similar discussion before on some bitbucket ticket that adding the major version to the project name is a "weird" choice and that you could use the version information to query a specific version of the CMake package rather than appending the major version to the project name.

We also don't plan to support ament_tools in the future. I would suggest you should update the name in the manifest to match the CMake project. Arguably that will affect the packages declaring dependencies on this one (which is why I would suggest a naming scheme without the version number being part of the project name).

[dirk-thomas]

I will close this for now since I don't expect that we will support two different names for a package (manifest name being different than e.g. CMake project name). Please feel free to continue commenting here.

[croesmann]

Sorry for replying to this old issue. Actually, I ran into a similar problem while trying to release libg2o into ROS2. I am trying to port the Bloom-ReleaseThirdParty workflow to ament. The original 3rd party package uses project(g2o) in the CMakeLists.txt while the ROS package is called libg2o, at least in ROS1. As a consequence, package and library files are installed into install/g2o/ rather than into install/libg2o.
I thought about patching project(g2o) in CMakeLists.txt, however, this requires many changes and potential dependency problems in the whole 3rd party project.

Has anyone already had experience with 3rd party packages, or is there already a best practice?

edit: this in fact concerns ament_cmake instead of ament_tools. I can open a new issue there, but depending on the topic and discussion I placed it here for now...