Comments (4)
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?
from ament_tools.
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 toproject()
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).
from ament_tools.
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.
from ament_tools.
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...
from ament_tools.
Related Issues (20)
- changing ament install prefix doesn't change the cmake install prefix HOT 2
- uninstalling after installing to a different directory HOT 5
- uninstall verb fails HOT 1
- We should validate ament_cmake packages after installation HOT 6
- Sourcing overlay workspace's setup file isn't enough for python packages HOT 2
- ament build_pkg doesn't respect other verbs HOT 10
- assert that ament_cmake packages register in the ament_index HOT 2
- No setup.bash for --isolated compilation HOT 2
- Add error summary at the end of `ament test` HOT 4
- Proposal: make `ament test` return non-zero on test failure HOT 5
- Parallel build waiting for package forever HOT 1
- Symlinked overlay installation doesn't have preference for ament_python packages HOT 8
- option to build only a package and its dependencies HOT 6
- Build of package on windows hangs sometimes HOT 2
- Because of unquoted path ament fails on Windows HOT 3
- Test Report Generation for ament test tools HOT 2
- SyntaxError when building pure Python package with Extension HOT 6
- Failed to compile extension due to out-of-source build HOT 5
- python3-pytest doesn't support option "-o" and it results in error while running python unittest of a ros2 component HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ament_tools.