This new command line tool has the same CLI as current manage.py
scripts, but automatically loads "langkit.yaml" files configurations, so
that language specs do not have to write Python code to subclass
ManageScript.
The "create-project.py" executable wrapper file created by setuptools
was crashing with an error:
Traceback (most recent call last):
File "<frozen runpy>", line 198, in _run_module_as_main
File "<frozen runpy>", line 88, in _run_code
File "C:/Users/User/Documents/Programs/msys64-1/msys64/ucrt64/bin/create-project.exe/__main__.py", line 4, in <module>
ModuleNotFoundError: No module named 'langkit.scripts'
because the source file "langkit/scripts/create_project.py" was not
added to the wheel archive.
Stop using setuptools' "scripts" feature, now obsolete and bound to
create issues in the future, and use the newer
entry_point/console_script mechanism instead to create the same
command-line tool.
Preserve the "scripts/create-script.py" executable source for
development environment convenience.
This commit stops considering Langkit_Support as a generated project:
* move the "langkit/support" directory to "support" (not
"langkit_support" for convenience with tab-completion);
* move the meat of the "langkit_support_gpr.mako" template to the static
"langkit_support.gpr" file, and remove the template;
* remove the "build-langkit_support.py" script and all the corresponding
libmanage.py/langkit_support.py code;
* enhance the top-level "manage.py" script to build/setenv
Langkit_Support and import the packaging tools from
"build-langkit_support.py".
From now on, Langkit_Support is a really a standalone library project,
and thus a "real" dependency for Langkit-generated libraries.
TN: T914-012
So far, this testcase assumed that the "langkit" package was in a source
tree, whereas in the Travis CI setup, it comes from the setup.py
installation. Register the build-langkit_support.py script and introduce
PATH lookup in the misc/link_two_libs testcase to make it work on
Travis CI.
TN: T511-017
