Optional Dependencies in LLDB

Hey everyone,

I just wanted to let you know that most of the work is complete for
auto-detecting optional dependencies in LLDB. Unless explicitly
specified, optional dependencies like editline will be enabled when
available and disabled otherwise. This is different from the old
behavior, where optional dependencies were that were enabled by
default would cause an error at configuration time. The motivation is
to make it easier to build LLDB by making things "just work" out of
the box.

All optional dependencies are now controlled by an LLDB_ENABLE_* CMake
flag. The default value for these variables is "Auto", which causes
the dependency to be enabled based on whether it was found. It's still
possible to obtain the old behavior by setting the corresponding CMake
variable to "On" or "Off" respectively.

If you have a configuration where you were depending on the old
behavior where the dependency being enabled or disabled by default,
you might want to consider passing LLDB_ENABLE_*=On/Off to CMake to
ensure the dependency is required or ignored respectively.

TL;DR Optional dependencies in LLDB are controlled by LLDB_ENABLE_*
CMake flags and are auto-detected by default. You can return to the
old behavior by setting the variables to "On" or "Off" respectively.

I think (didn't test at the moment, just browsed the cmakefiles) one case that still isn't handled properly, is the interaction between python/lua and swig. If python or lua are detected, they are enabled, and then the build strictly requires SWIG to be present.

I think we should check for SWIG first and require it to be present before automatically enabling python and lua.

// Martin

> I just wanted to let you know that most of the work is complete for
> auto-detecting optional dependencies in LLDB. Unless explicitly
> specified, optional dependencies like editline will be enabled when
> available and disabled otherwise. This is different from the old
> behavior, where optional dependencies were that were enabled by
> default would cause an error at configuration time. The motivation is
> to make it easier to build LLDB by making things "just work" out of
> the box.

I think (didn't test at the moment, just browsed the cmakefiles) one case
that still isn't handled properly, is the interaction between python/lua
and swig. If python or lua are detected, they are enabled, and then the
build strictly requires SWIG to be present.

Yup, good point, that's still on my TODO list.

I think we should check for SWIG first and require it to be present before
automatically enabling python and lua.

That would make sense, but I haven't gone that route because
downstream (Swift) we have the Python bindings checked-in. So it's not
necessary to have SWIG in order to enable Python. Of course downstream
shouldn't direct what we do upstream, but if I can figure out a
solution that minimizes divergence I strongly prefer that. I'm hoping
to get to this soon.

After trying it out I concluded that it should be easy enough to check
for the static bindings flag in FindPythonInterpAndLibs.cmake so I've
implemented your suggestion in fc6f15d4d2c. Thanks again for bringing
this up.

Awesome, thanks!

Do I understand this correctly that something similar still would be needed for Lua though?

// Martin

Yes, that's correct. This was added in edadb818e5b.

This "explicitly specified" mode makes it possible to declare that I want it to be hard error if an optional dependency is missing (e.g., to avoid silently dropping editline support by accident)?

-- adrian

>
> Hey everyone,
>
> I just wanted to let you know that most of the work is complete for
> auto-detecting optional dependencies in LLDB. Unless explicitly
> specified, optional dependencies like editline will be enabled when
> available and disabled otherwise.

This "explicitly specified" mode makes it possible to declare that I want it to be hard error if an optional dependency is missing (e.g., to avoid silently dropping editline support by accident)?

Correct, setting any of the LLDB_ENABLE_* to ON and the dependency not
being found will cause a CMake configuration error.

Thanks!

// Martin