-
Notifications
You must be signed in to change notification settings - Fork 64
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
Removal of "No CMake" build option #1299
Conversation
The #line directives make debugging impossible and obfuscate the generated code. I should re-enable them before merging to main.
Just to see what would happen.
We have informally discussed setting the margins in this way. I decided not to wait any longer for the opportune moment to make this change.
94a232c
to
fa5a530
Compare
fa5a530
to
cfe94ff
Compare
350d199
to
1952c8f
Compare
Do not use a C++ compiler for the runtime. Only use a C++ compiler for the generated code.
This is a work in progress. In particular, setup.py is broken.
This removes interaction with Python package management systems such as Pip from the LF build process. We do not need to install the C extension module in the user's environment because it is sufficient to have a naked .so or .dll sitting in the `src-gen` directory.
This includes an attempt to pass federated and docker tests.
This also keeps the file names that existed in master in org.lflang.generator.c and org.lflang.generator.python.
b7c45ab
to
34f9e76
Compare
4a6f3a9
to
9ad319b
Compare
This follows up on a conversation with @arengarajan99 and Marten about the Arduino tests. The rationale is that soon, our Arduino support will be entirely different anyway, and that we can tolerate a temporary regression in the interim as a shortcut to save person-hours. Obviously I take responsibility if we have to scramble to get support back in time for a release.
This is a hack! The fact that it is needed is a reflection of the fact that the changes introduced by this PR leave the build system sensitive to idiosyncrasies in the way Python is installed and discovered on the system.
In this case it should be helpful to get the verbose output of cmake and compare the executed commands in CI to a local run. |
I did as Christian suggested and can confirm that CMake is discovers a different version of Python than what is discovered by
Basically, one Python is in the Cellar, and the other is not. There are ways to fix this, e.g., by explicitly specifying the path to Python when we invoke CMake.; furthermore, I know where in the code base this change would have to be made. However, there are a few reasons to stop here:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great! Congrats on finally getting this PR to pass the tests!! 🎆 I left some comments/requests. I wonder how much trouble these changes will give us in fed-gen
... Perhaps you could assist with the merge? I haven't reviewed the changes in reactor-c
yet. I will do that next.
Looks like there is no accompanying PR for |
Co-authored-by: Marten Lohstroh <[email protected]>
This branch deletes over 500 LOC and breaks the "no CMake" build option that directly invokes the C compiler. The corresponding PRs in
reactor-c
andreactor-c-py
should be merged first.It's a bit of a work-in-progress, but I wish to rush this into master to mitigate conflicts. I promise to help resolve any conflicts that result in the
fed-gen
branch.