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.