-
-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unfound includes passed through despite NO --passthru-unfound-includes
#85
Comments
A repro would be nice. |
I doubt if it's specific to anything. Anyway, here's a repro:
Input: fpdfview.h.txt (from pdfium) What I was actually experimenting with is calling pcpp through pypdfium2 ctypesgen:
but ctypesgen's parser fails at the include retained by pcpp, resulting in an empty output file. ctypesgen expects a gcc or clang compatible C pre-processor, but I notice pcpp seems to behave somewhat differently. For one thing, it doesn't understand system includes on its own. (I've been looking for a pure-python solution to relieve the dependence on system packages.) |
FWIW I could get rid of all unfound includes by adding
It seems like pcpp does not actually resolve these names, whereas clang does: // present with clang, missing with pcpp
typedef __uint8_t uint8_t; |
pcpp also returns a failure exit code. The file output is a "best effort" in that circumstance, and will emit those header files it failed to include as-is. It's up to what calls pcpp to handle things appropriately. I did:
... and got no error from either GCC or clang. I then did:
... and compared pcpp's and GCC's output, and they were identical apart from whitespace in places. Both outputs are attached so you can see for yourself. |
Can you retry with all pdfium headers (download link) ? |
@ned14 However, then the question is, why is there |
Unless you specify all of the built-in macros which GCC has i.e.
then pcpp will generate output like:
because it hasn't been told to do otherwise. Generally it's much easier to have pcpp output inclusion of |
Ah, so if we passed all the gcc/clang default defines to pcpp, it would include e.g. the
ctypesgen needs a fully parsed output that aligns with "real" C pre-processors. AFAIK, the partial form just isn't eligible for our use case. |
Correct. BUT gcc/clang's default defines vary according to configuration, architecture, platform and version. I don't know how you'd avoid invoking gcc or clang to go get its default defines, and if you have to bother doing that, you might as well have it do the preprocessing too. |
I made some progress, but still didn't manage to get ctypesgen play with pcpp. gcc -dM -E - < /dev/null > ../default_defs.h
ctypesgen -i fpdf*.h -l pdfium -L . -o ../bindings.py --preproc-savepath ../preproc_out.h --cpp "pcpp -I . -I /usr/lib/gcc/x86_64-redhat-linux/12/include -I /usr/local/include -I /usr/include --line-directive '#' ../default_defs.h" It fails with
because pcpp retained the Note that pcpp did not return an error code or log the failure in this case. |
Ah, wait, actually the above already partially works. 🎉 ctypesgen does produce a list of members, they just aren't included, so we need to add Updated command:
|
Cool |
However, the resulting bindings are still incomplete. When plugging into pypdfium2, the test suite shows the following error:
It seems like some macro constant defines are missing. |
I'm getting unfound includes passed through to the output file although I did not specify
--passthru-unfound-includes
.Am I using the tool wrongly ... ?
The text was updated successfully, but these errors were encountered: