search

hpyproject / hpy

HPy: a better API for Python
https://hpyproject.org
MIT License
1.02k stars 52 forks source link

Integration into projects that embed Python and use cmake #438

Open KubaO opened 1 year ago

KubaO commented 1 year ago

I'm working on a proof-of-concept for using HPy as a Python API inside of the open-source Electronic Design Automation (EDA) project KiCad. KiCad embeds Python, and uses it to allow application scripting. I'm looking for ways to make KiCad's binding to Python more universal, so that other implementations could be used in place of CPython. At the moment this is just to see if it's feasible.

Since KiCad embeds Python, it makes most sense to use it as a static library. KiCad uses cmake as a build system. I've added a CmakeLists.txt to our copy of HPy, so that it can be built together with everything else.

Would the HPy project consider having a maintained CMakeLists.txt at the root folder worthwhile? This would make it easy to drop HPy sources into a project and have them built. Only a ctx library would be built, since that would be the common use case I believe.

Would such a CMakeLists.txt and any needed CI stuff for it be accepted as a contribution to HPy?

This is the other side of the coin mentioned in #370

fangerer commented 1 year ago

Please don't be confused by our Makefile. We just use GNU Make as an convenient entry point. As you might have seen, we immediately call Python in the Make targets.

I'm generally not objected to have a CMakeLists.txt but I'm not sure if it makes sense. On CPython, HPy is usually just install via PIP. I think what you try to achieve is to bundle HPy with CPython such that you don't need to install it. I don't know the restrictions of your application but isn't it just possible to install HPy via PIP or something? Even if CPython is embedded, you can just eval Python code that would do this installation, right?

Since you mentioned #370: This one is more about how HPy extension developers can use setuptools to build and distribute their extensions.

KubaO commented 1 year ago

KiCad embeds CPython and adding external "prepackaged" dependencies is more pain than it's worth, since those dependencies have a tendency to break the builds. A lot of time was spent for example in keeping wxPython building.

KiCad is distributed for Linux, MacOS and Windows, so having in-tree dependencies that are built just like the rest of the source code makes most sense. That way any build issues can be easily addressed from the IDE.

KiCad goes as far as having many dependencies be in-tree copies, not git submodules. It makes checkouts fast, and makes any changes to such dependencies easy to audit.