For C flags, only use CFLAGS environment variable #544
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
srijan-paul
approved these changes
May 26, 2022
Now, the official way to affect the C compiler is to use the CFLAGS environment variable. This is a cleaner separation of duties. It also paves the way for using Luarocks as the compilation backend, because Luarocks only allows setting custom flags via the CFLAGS environment variable.
This removes debugging (-g) and warning (-W) flags in a default invocation of pallenec. Again, the main reason is to pave the road for the Luarocks compilation backend, which requires that any custom flags be passed via the CFLAGS environment variable. However, I think it is still a good idea despite that. Removing -g leads to smaller binaries and faster compilation times. As for the warning-related flags, they are not relevant to Pallene end-users, they are only relevant to us who are writing the compiler.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
To address #516, I'm planning to use Luarocks as a compilation backend. If we set things up the right way, we should be able to use Luarocks to compile our
cfiles into shared libraries, in a cross-platform manner.This PR has some CFLAGS-related changes to pave the way for that. When using Luarocks to build C modules, the only way to pass CFLAGS is via the CFLAGS environment variable. So what this commit does is take the flags we were passing directly in the c_compiler.lua and passing them via CFLAGS environment variable instead. This implies in a change in behavior. By default we will no longer compile with -g and -Wall. IMO, that might actually be a good thing. The -g causes larger executables and the -Wall is not relevant to end-users. (I'm still leaving the -Wall in the ./run-tests though)