docs: differences in design between llpyg and llcppg

[toaction]

What are the differences in design between llpyg and llcppg? Including product design and architecture design.

[toaction]

1. Target Languages

• llcppg targets C/C++ libraries, handling statically typed languages
• llpyg targets Python libraries, handling dynamically typed languages

2. Symbol Information Extraction Methods

• llcppg static analysis: C/C++ libraries have clear header file definitions, using libclang to parse header files, obtain AST, and get type and function declarations

• llpyg dynamic analysis: Python libraries don't have unified symbol definition files, currently leveraging CPython API and using reflection to obtain symbol information

llpyg can parse AST, but it requires significant effort and has certain difficulties

3. Type Handling

llcppg type handling: Matches header file declarations with library symbols and handles complex type mapping.

// llgo:link (*BZFILE).Read C.BZ2_bzread
func (recv_ *BZFILE) Read(buf c.Pointer, len c.Int) c.Int {
	return 0
}

llpyg type handling: Primarily uses *py.Object as a universal type, including parameter and return value types.

After improving class support, type conversion functionality for return values will be added.

//go:linkname A py.A
var A *py.Object

//llgo:link (*Dog).Speak py.Dog.speak
func (d *Dog) Speak(msg py.Object) *py.Object {
	return nil
}

4. Configuration Files

llcppg configuration file (llcppg.cfg):

{
	"name": "zlib",
	"cflags": "$(pkg-config --cflags zlib)",
	"libs": "$(pkg-config --libs zlib)",
	"include": [
		"zlib.h",
		"zconf.h"
	],
	"deps": ["c/os"],
}

llpyg configuration file (llpyg.cfg):

{
  "name": "numpy",
  "libName": "numpy", 
  "modules": ["numpy", "numpy.random"]
}

• The cflags and libs fields in llcppg.cfg serve the same purpose as the libName field in llpyg.cfg, both aiming to locate the source code of the library to be processed.
• The include field and modules field serve the same purpose, indicating which files/modules to process
• The deps field is used to declare library dependencies, which is needed during type processing. Python has similar requirements, but currently everything is unified to py.Object type. Dependency declaration functionality will be added in the future.

5. Architecture Design

llcppg and llpyg have similar processing logic for generating LLGo Bindings, roughly consisting of three stages: symbol information extraction -> function signature parsing/type processing -> Go code generation.

The main differences lie in the processing approach:

• llcppg extracts symbol information by parsing header file AST, while llpyg obtains symbol information by importing modules and using reflection
• llcppg maps various types, while llpyg unifies everything to py.Object

Summary

Due to the fundamental differences in target languages, they have significant differences in design and implementation. llcppg focuses more on static analysis and complex type system handling, while llpyg relies more on runtime reflection and simplified object models.