Skip to content
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

No developement support for pycparser on Darwin #473

Open
vit9696 opened this issue Sep 10, 2022 · 2 comments
Open

No developement support for pycparser on Darwin #473

vit9696 opened this issue Sep 10, 2022 · 2 comments

Comments

@vit9696
Copy link
Contributor

vit9696 commented Sep 10, 2022

#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.

@vit9696 vit9696 changed the title Not developement support for pycparser on Darwin No developement support for pycparser on Darwin Sep 10, 2022
@eliben
Copy link
Owner

eliben commented Sep 12, 2022

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
Copy link
Contributor Author

vit9696 commented Sep 26, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants