frontend.py
is a library that takes an AST defined by IR::IR
and writes pybind11
code. The idea is to be able to use the C++ code that corresponds to the AST from python
via the generated pybind11
.
frontend.py
is a part of the Tolc
project and is used to support creating CPython
bindings via pybind11
.
frontend.py
can be built on Linux, MacOS, and Windows. See the CI pipelines for more platform specific information..
Here is a general overview:
Requirements:
- CMake
- python3
- conan
- clang
Configure the project:
$ cmake -S. -Bbuild -G Ninja -DCMAKE_CXX_COMPILER="clang++" -DCMAKE_C_COMPILER="clang" -DCMAKE_BUILD_TYPE="Debug" -DENABLE_TESTING=ON -DENABLE_PACKAGING=ON
Build tolc
:
$ cmake --build build
Test with ctest
:
$ cd build
$ ctest --output-on-failure
Install with CPack
:
$ cpack -G TGZ --config build/CPackConfig.cmake
C++
uses many 'valid' styles when naming things. A function with a camelCase
name such as myFunction
would be considered fine in C++
but unconventional in python
where snake_case
is more 'pythonic (see PEP8 for more information). To avoid confusion when converting existing C++
these case transformations should be opt in.
You should be able to completely change the python
interface as long as it does not change the C++
. This means that each logical module in frontend.py
must have an internal interface, for things like the C++
fully qualified names, and an exposed interface that is public to change.
It is highly likely that when converting a large library, you may want to tweak things. It should then feel natural to add some lines to the output without getting a heart attack scrolling through obfuscated code. This practically means:
- Format the output the same way the current code is formatted (see .clang-format).
- Note that the user can post format. Focus on readability.
- We should not output more code than what is needed.
In some unique cases these rules may need to be broken, but you should consider them strict guidelines.