Can you pls make troubleshooting easier?

I find the build process complicated and hard to debug, a couple of suggestions:

• can you consider improving the names, liblktlang, liblktlang_support, langkit_support, ... way too many "l"s "k"s and "lang"s.
• the python build process obscures things - it says for example it generates files and does not say where
• there is no obvious way to simply enable gprbuild and gprinstallverbose modes - changing python is needed
• https://no-color.org/ has nice suggestion - you could check for the NO_COLOR environment variable (or maybe also CI) in the langkit.utils.colors
• a mishmash of Python mixed into Ada code is not nice (and probably a horror for packaging). Until we have a first class support for Python in gprbuild maybe it could be separated somehow...
• this looks scary - can this be surpressed? `

Subcommand failed: error while running /usr/local/bin/python3.11 /usr/home/saper/src/ada/langkit/lkt/check_bootstrap.py -q:
    Command '['/usr/local/bin/python3.11', '/usr/home/saper/src/ada/langkit/lkt/check_bootstrap.py', '-q']' returned non-zero exit status 1.

• The steps of the process are confusing the README says

Build the Liblktlang support library:
$ python manage.py make --no-mypy --library-types=static,static-pic,relocatable

But this seems to build more than just that library.

Do I get it right that logical steps of the build process are:

1. python3 manage.py build-langkit-support (all library types if needed)
2. python3 manage.py install-langkit-support (all library types if needed)
3. python3 manage.py bootstrap - this builds relocatable library only in lkt/bootstrap/lib/relocatable/dev/liblktlang.so
4. some code generation
5. ...

Start by reading langkit/utils/colors.py, the README build instructions, manage.py entry points, and lkt/check_bootstrap.py. Separate the checklist into independently scoped improvements, then define completion criteria for build output, verbose-mode controls, color handling, error reporting, naming, and documented build steps.