Separate PYTHON_MODULE into its own subproject

[LecrisUT]

Looking through the build logic, the build process looks very weird and it does not allow incremental build or reusing of older build artifacts. The suggestion is to separate the library component and make it available via a export(EXPORT) and install(EXPORT), so that packagers can link to a common installed library instead of duplicating the symbols in the python module as well. This will also make it easier to use standard python build-systems and include dist-info python metadata, e.g. the modern way of checking a python project's version is to use importlib.metadata which would not work without the mentioned metadata files.

[GillesDuvert]

@LecrisUT certainly. The python bridge is all old code, unmaintained. All suggestions to make this more manageable by new people is welcome. Would you be more precise in your suggestions? Like, submitting a PR ?

[LecrisUT]

Writing a PR will take me some time as I would have to untangle the current build system. I can offer instead my project (spglib) as an example workflow and offer review support. The basic is having separate independently buildable subprojects, e.g. a basic structure could be

.
├── cmake                   (CMake helpers)
│   └── gdlConfig.cmake.in
├── CMakeLists.txt          (Main project entrypoint)
├── src
│   └── CMakeLists.txt      (Implementation details of the main project)
├── example                 (Self-contained example CMake projects)
├── python
│   ├── CMakeLists.txt      (Python api project (Self-contained))
│   └── gdl                 (Pure python package sources)
└── test
    ├── CMakeLists.txt      (Self-contained test-suite)
    ├── example
    ├── regression
    ├── package
    └── unit

Here Self-contained would refer to having a check that would allow to be run as an independent project, usually

if(NOT TARGET GDL::gdl)
    find_package(GDL REQUIRED CONFIG)
endif()

[slayoo]

IIUC, this is what is already done in the Debian packaging workflow: https://sources.debian.org/patches/gnudatalanguage/1.1.1-1/Create-a-shared-library.patch/

[LecrisUT]

Partially, it addresses the issue of having to rebuild, but the projects are not independent, and there is little control on how to build it.

[GillesDuvert]

@slayoo I wonder why such patches from our dear distro maintainers are not systematically retrofitted in the master code...

[slayoo]

@slayoo I wonder why such patches from our dear distro maintainers are not systematically retrofitted in the master code...

@olebole did propose it as a patch back 10 years ago: https://sourceforge.net/p/gnudatalanguage/patches/95/ and it was later tracked here: https://github.com/gnudatalanguage/gdl/issues/49 but closed

[GillesDuvert]

In order to simplify maintainance, It would be great to have the pythonGDL 'project' installed in a separate GH repository (as gdlde and gdl-kernel, and in // with other subprojects such as publishing on flathub, etc). And certainly have GDL produce a libgdl.so in all cases, with separate executables linked to this library.