Default script language

In lldb/include/lldb/lldb-enumerations.h we have:
eScriptLanguageDefault = eScriptLanguagePython

I'd like to do something like:
#if LLDB_ENABLE_PYTHON
eScriptLanguageDefault = eScriptLanguagePython
#elif LLDB_ENABLE_LUA
eScriptLanguageDefault = eScriptLanguageLua
#else
eScriptLanguageDefault = eScriptLanguageNone
#endif

if we could include Config.h, or achieve the same effect in some other
way if we cannot. Does this seem reasonable?

I'm interested in this for lldb in the FreeBSD base system. We have
lua available already (and no python) and I've integrated our liblua
it into lldb, but it required "--script-language lua" on the command
line. For now I'll just change the default to be eScriptLanguageLua in
our tree, but would like to have this "just work" upstream.

Why default to none if python and lua aren't available instead of defaulting to shell scripting?

I'd be fine with your #ifdef approach. Anyone else?

For scripting to working it must support classes and Swig must support creating bindings for the entire public API. Don't think shell scripting can do that.

Greg

Right now, Lua is not nearly as well supported as Python, so it makes sense that if both Python and Lua are available Python should be the default. But at some point Lua will become an equal to Python. When that happens, it seems to me the default scripting language choice should be up to the package distributor. I don’t see why we need to weigh in on that. That would imply that the default should be an independent build setting. Not sure that means we need to do it that way now, but if we don’t want to do it twice…

Jim

I agree with Jim - it should be a cmake setting, defaulting to Python. If the person building lldb wants to change the default scripting language from Python to Lua, it should be easy. Since we now support 2 scripting languages, we should have an easy way for the user to see which are supported, and which is the default if there are more than 1 supported. Maybe in lldb --version?

Ted

+1 for making this a cmake option.

That said, I don't think we can implement this using #ifdefs.
lldb-enumerations.h is a part of our public api, Config.h isn't (it
theoretically could be, but I don't think we want that).

I think the simplest way to achieve this would be to make
eScriptLanguageDefault an enum value in its own right, and handle the
translation to an actual language internally.

pl

I agree with Jim - it should be a cmake setting, defaulting to Python. If the person building lldb wants to change the default scripting language from Python to Lua, it should be easy.

Ok, agreed. My initial concern was that python remained the default
even if not compiled in, but I can carry a tiny patch in the FreeBSD
base system to address that for now. I agree with Jim that there's no
point in doing the work twice.

Since we now support 2 scripting languages, we should have an easy way for the user to see which are supported, and which is the default if there are more than 1 supported. Maybe in lldb --version?

We should indeed have a way to see which languages are available and
which is default. We have a few other build-time options, should we
include a summary of all of them in --version I wonder?