renaming LCM (imported) targets

[Matthew Woehlke]

Drake¹, a major consumer of LCM, is in the process of transitioning to
Bazel² as its build system. As a consequence, we need Drake to build LCM
via Bazel, but then export LCM so that CMake consumers can find and use it.

I am hoping to teach Bazel to output a CPS³ that will replace⁴
lcmConfig.cmake and associated files. However, one complication is that
CPS *requires* that targets are namespaced. That being said, CMake
already recommends doing this.

I would like to propose renaming the (imported) LCM targets to start
with `lcm::`. (Unfortunately, there does not seem to be any backwards
compatible way to do this.)

Questions:

1. Is this a reasonable/acceptable thing to do?

2. What should the new targets be named?

Right now we have lcm-coretypes, lcm, lcm-static, lcm-gen, lcm-java. I
am wondering, first, if we want to name the imported targets like
lcm::lcm-java or lcm::java (implying that the internal target would also
be renamed, i.e. `make lcm-java` becomes `make java`), and also, should
the main shared library be lcm::lcm, lcm::shared, lcm::lcm-shared, ...?

For now, LCM won't otherwise notice CPS; it's only necessary that the
imported targets from the CMake build (which is not being replaced in
LCM itself) are namespaced so that it is possible to craft a CPS that
will have the same target names.

(¹ http://drake.mit.edu/)
(² http://bazel.build/)
(³ https://mwoehlke.github.io/cps/)
(⁴ Actually, in the short term - at least until CMake learns to read CPS
directly - we will generate a lcmConfig.cmake from lcm.cps.)

--
Matthew

[Matthew Woehlke]

ping?

Matthew

[Matthew Woehlke]

On 2017-05-10 17:45, Tim Perkins wrote:
> I'm replying directly to try and get some clarity on what you're asking.

Re-adding the list because you raise a fair point and I may be confusing
others.

> Are you saying you want to move LCM to a new build system? (But didn't you
> just get all this CMake stuff working?) Or do you only want to move CMake
> targets into an "lcm" namespace, so they're compatible with this other
> project?

No. TBH, Bazel has... issues, to the extent that I would specifically
recommend that any open source project *avoid* Bazel.

I won't go into all the politics and pain of Drake switching to Bazel,
but the relevant point is that, due to the way Bazel works and the
desire for a build that bundles everything, LCM is *de facto* being
built by Bazel in Drake. The need to make this play nice with downstream
consumers lead me to restart work on CPS (link in previous mail).

CPS aims to be a portable (read: usable by many tools, not just CMake)
replacement for pkg-config and CMake exported targets. The idea is that,
in the short term, Drake would produce an lcm.cps that is compatible
with LCM's upstream CMake build, so that Drake can export an LCM that is
transparently interchangeable with an upstream (CMake) build. In the
longer term, the goal is for CPS to replace CMake exported targets as
the preferred way to export packages built by CMake. For CMake users,
this would be *mostly* transparent, but it would make it *much* easier
for non-CMake projects to consume a package built by CMake. (It also
provides a mechanism that is more plausibly usable by non-CMake systems
to produce a package description that - unlike .pc's - is suitable for
CMake's consumption).

The hitch - the reason for "mostly" in the above - is, as stated, that
CPS components are *always* namespaced, by design. This is actually
considered best practice in modern CMake also. (Really, I should have
namespaced LCM's targets from the start. My bad.)

I don't intend to replace CMake in LCM upstream, but I *would* like to
make LCM compatible with CPS... not just for Drake's sake, but for
"future proofing", and because namespaced targets are TRTTD anyway.

I did realize, last night, one thing that may help. If we're okay with
just adding the namespace but otherwise leaving the target names
unchanged (so: lcm::lcm, lcm::lcm-static, lcm::lcm-gen, lcm::lcm-java),
I'll also add `LCM_NAMESPACE=lcm::` to lcmConfig.cmake. This way, users
can link to `${LCM_NAMESPACE}lcm`, which will transparently work for
both the current setup and the new namespaced setup.

(There are additional ways for consumers to support both versions, but
the above is likely the least change on the consumers' side.)

--
Matthew