Note: I'm not sure that version_gte="0.2.3" still applies. I think that we assume std::shared_ptr types in urdfdom that are provided only by v1.0 and higher

Note: I'm not sure that version_gte="0.2.3" still applies. I think that we assume std::shared_ptr types in urdfdom that are provided only by v1.0 and higher

I've been making only necessary changes. If you want it gone in this PR, can you confirm it, otherwise, it's something that can be addressed later.

Later is fine, I just thought it was worth noting but don't know what the minimal version we require actually is

This patch breaks the default branches. Please either fix asap or revert this change.

I used https://gist.github.com/dirk-thomas/001152f81a352aba3bb87c302ae1c42d to confirm that reverting this makes the build pass again.

I also don't see any CI builds for this set of changes. Did you run any or build the changes locally?

The root cause of the build failure introduced with this PR is with build ordering when the package.xml dependency key and ament package name are not the same.

By changing the dependency key from urdfdom_headers to urdfdom-headers and changing the urdfdom_headers package name to urdfdom-headers only in the release-provided package.xml ament could not correctly insure that the cmake package urdfdom_headers needed to be built before urdfdom.

I tested some permanent fixes locally. Bringing the release package.xml into the source directory causes ament to raise an InvalidPackage exception due to the dashed name.

Omitting the package.xml and trying to change the cmake project name causes ament to be unable to find the package because it no longer satisfies this regexp.

I'm not sure what the best thing to do is. The least creative would seem to be to return to the original plan of changing the urdfdom-headers downstream packages to depend on urdfdom_headers (note underscore) with a comment that this dependency should be updated when the system urdfdom-headers is suitable.

Did you run any or build the changes locally?

I was running the changes locally, both for expedience and because I'd seen mailing list chatter about ci bottlenecks, and because I had not expected package.xml dependency keys to affect the build. This was my oversight and I'll run subsequent package.xml changes through CI.

I was running the changes locally

Are you building locally with --isolated?

Are you building locally with --isolated?

I was not.

Are you building locally with --isolated?
I was not.

You should build with --isolated in order to detect dependency problems. Probably making an alias is the best atm (until the option is enabled by default).