Mention that ctypesgen requires gcc

[mara004]

It should be mentioned somewhere in the readme/description that ctypesgen needs gcc, ideally with installation instructions for the various platforms. I also find the term pure-python kind of misleading if gcc is involved. ¹

Footnotes

1. Although it's correct in the sense that ctypesgen itself is written entirely in Python, I feel like pure-python somewhat feigns "standalone" (i. e. independent of compiled binaries other than Python itself) in the current context. ↩

[mara004]

Also, ctypesgen should fail if gcc is missing, instead of producing a file that only contains the library loader template but no actual bindings.

[nilason]

You are right, it should be mentioned also early on in the Readme file.

It is, however, mentioned that a C (pre-)compiler (clang is also working just fine) is needed in https://github.com/ctypesgen/ctypesgen/wiki/Getting-Started.

[mara004]

Ah, you're right, I completely forgot about the Wiki, although it's mentioned (but the projects I commonly work with don't have one). Sorry for overlooking this!

[demberto]

MSVC works for me by specifying --cpp="cl -E", although I cannot verify if the output is correct.

EDIT: Yes, the output is incomplete with MSVC

[mara004]

clang is also working just fine

However, ctypesgen always wants gcc by default, even if clang is present but gcc is not.
Anyway, I have now implemented auto-detection using shutil.which(...) in pypdfium2-team@7559e81 ff.

I've also done some search for pure-python pre-processors, but AFAICS they're not currently near enough an emulation of gcc/clang to be usable in ctypesgen. See also ned14/pcpp#85 (comment) f.

[mara004]

Yes, the output is incomplete with MSVC

@demberto Could you elaborate on why it fails or what is missing in the preprocessed header? (you may use --save-preprocessed-headers $FILENAME for inspection)
Unless MSVC's output is actually wrong, perhaps ctypesgen's parser could be made compatible with what MSVC does differently?

[demberto]

I am no longer looking into this nor have the time to do it. (I'm out)

[mara004]

I am no longer looking into this nor have the time to do it. (I'm out)

OK, sorry for directing the question at you then.

I rather meant, if someone has access to MSVC and time/interest to investigate, it would be nice to get some information on why it fails. But that doesn't necessarily mean I'll have time to look into it, either.
Actually I'm under time pressure too and not sure how long I can continue to actively commit to pypdfium2/ctypesgen.

[nilason]

clang is also working just fine

However, ctypesgen always wants gcc by default, even if clang is present but gcc is not. Anyway, I have now implemented auto-detection using shutil.which(...) in pypdfium2-team@7559e81 ff.

There's no way to know which compiler would be the default compiler, there may be several installed in a machine, the gcc is the default option defined in:

ctypesgen/ctypesgen/options.py

Lines 12 to 19 in 17b7a25

	default_values = {
	"other_headers": [],
	"modules": [],
	"include_search_paths": [],
	"compile_libdirs": [],
	"runtime_libdirs": [],
	"cpp": "gcc -E",
	"allow_gnu_c": False,

but may be changed to whichever you like (with the cpp option).

[mara004]

The point is this: there may be only clang available but not gcc. In that case, it is good to dynamically select as default the one that is available. This is ctypesgen's task, not the caller's.
To be clear, I am not talking about removing the cpp option or something, just a smarter default. See the referenced commit for implementation.

[mara004]

pypdfium2-team@7559e81#diff-10efdf366a5ecfb798faac7c47024648aa3a2552abe209fadc128c8c847d3dd1R354