search

eliben / pycparser

:snake: Complete C99 parser in pure Python
Other
3.26k stars 612 forks source link

No developement support for pycparser on Darwin #473

Open vit9696 opened 2 years ago

vit9696 commented 2 years ago

https://github.com/eliben/pycparser/pull/471 was closed, but the original issue: being unable to run all the tests on Darwin, which is the development platform for a fair amount of people, including myself, persists.

It is much easier to test various C code by simply editing a .c file rather than using a python-script, so preprocessor integration for the tests is a very convenient and useful thing.

What approach would you suggest to address this issue? I am fine to redo the PR with a better design.

eliben commented 2 years ago

The problem is that these preprocessing tests actually test very little - only this trivial function https://github.com/eliben/pycparser/blob/master/pycparser/__init__.py#L18, which itself just invokes an external command.

This is not a core part of pycparser; it's just a utility it provides, and it has caused an unreasonable amount of trouble because of the different environments people use - cpp exists, cpp doesnt exist, cpp handles subset of preprocessing tasks, gcc exists, gcc doesn't exist, old gcc, etc etc.

To start off, I don't recommend feeding C source that requires preprocessing into pycparser at all. For your tests and local experimentation, use unpreprocessed C source and use_cpp=False to parse_file - which is also the default).

I'd much rather these tests don't run on Macs at all than have them run by default but get reports from users that "pycparser tests fail" on their machines. That code invoking cpp is trivial and hasn't really changed in many years. I think the testing exercise it's getting from running on Linux on GitHub actions is sufficient.

If you want to adjust the examples to invoke preprocessing properly, maybe we need a different approach. I don't think that every example needs to have a "if darwin do this, otherwise that" clause. There could be a more general solution, like setting the cpp path to use as an env var all examples could share

vit9696 commented 2 years ago

Point is less about testing preprocessor invocation in pycparser, but rather using more complex sources to test pycparser. I wonder if it is a good idea to reconsider pycparser defaults for the preprocessor depending on the operating system. If it invokes gcc -E inside, then there is no need to change tests, which seems to me a good idea. An environment variable can also do, but this feels strongly unintuitive for the end user.