This matches the naming scheme used by LLVM and all the other optional dependencies in LLDB.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lldb/cmake/modules/LLDBConfig.cmake | ||
---|---|---|
46 | I know that the same thing is done above but… what's the point of setting it to ON again? |
lldb/cmake/modules/LLDBConfig.cmake | ||
---|---|---|
46 | It's just setting the default to the old value. If the value was set, we should honor it, both if it was OFF or ON. |
lldb/cmake/modules/LLDBConfig.cmake | ||
---|---|---|
46 | But it's already set to ON a few lines above. |
lldb/cmake/modules/LLDBConfig.cmake | ||
---|---|---|
46 | Do you mean the DEFINED? That just checks if the variable exists, not its value. |
That seems like a simple mechanical change and the move from DISABLE to ENABLE was IIRC already consensus, so LGTM.
lldb/source/Commands/CommandObjectType.cpp | ||
---|---|---|
1173 | lol? |
lldb/cmake/modules/LLDBConfig.cmake | ||
---|---|---|
46 | No, I mean you have: set(default_enable_python ON) #... if (DEFINED LLDB_DISABLE_PYTHON) #... else() set(default_enable_python ON) This is superfluous since the default is already ON. |
lldb/cmake/modules/LLDBConfig.cmake | ||
---|---|---|
46 | Yeah, I added the curses stuff without too much optimization to keep the debian bot working until the master restarts (so the configuration change takes effect). I don't think we have any bots using LLDB_DISABLE_PYTHON, so this probably wasn't even needed, but this all isn't very important -- the code will be gone in a few days anyway... |
lldb/cmake/modules/LLDBConfig.cmake | ||
---|---|---|
46 | Btw, I've just removed the LLDB_DISABLE_CURSES blurb. If you don't know of any reason to keep LLDB_DISABLE_PYTHON python around (I don't) then I think that can go too... |
I know that the same thing is done above but… what's the point of setting it to ON again?