-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
zig run/cc: recognize "-x language" #13544
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
Conversation
Does this PR work with Something like: const exe = b.addExecutable("whatever", null);
exe.addCSourceFiles(&.{
"file1.c",
"file2.c",
}, &.{
"-x c++",
}); I know a bizarre project that only compiles when compiling Lua with a C++ compiler, and this would greatly help. |
wouldn't it be |
With the status-quo, my code above would be treated as C files because of their file extensions. And the stdlib currently only has Edit: That said, the name of |
cc @bfredl this is one of the prerequisites to compile neovim with |
Not in this PR. That could be added, but I am not sure if the approach will be accepted in the first place. So I will not extend the scope yet. |
1163b3a
to
4dec4b3
Compare
@sandhose's comment from #10915 (comment):
Thanks for providing the reproducible case. I've updated the PR and it no longer throws this error. Please test the current version. |
I build from this branch (macos) and it worked for me. Thanks! Looking forward to having a zig release with this |
Is it intended to add support to |
Once this is merged, you are welcome to do so, should be relatively easy if you have a use case. From my experience with working on this, it's difficult to add an extension without good understanding and example on how it will be used. |
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.
Excellent work. I see only one more thing to be done before merging, which is to add the new field ext
to the cache hash in the addNonIncrementalStuffToCacheManifest
(search for extra_flags
).
This commit adds support for "-x language" for a couple of hand-picked supported languages. There is no reason the list of supported languages to not grow (e.g. add "c-header"), but I'd like to keep it small at the start. Alternative 1 ------------- I first tried to add a new type "Language", and then add that to the `CSourceFile`. But oh boy what a change it turns out to be. So I am keeping myself tied to FileExt and see what you folks think. Alternative 2 ------------- I tried adding `Language: ?[]const u8` to `CSourceFile`. However, the language/ext, whatever we want to call it, still needs to be interpreted in the main loop: one kind of handling for source files, other kind of handling for everything else. Test case --------- *standalone.c* #include <iostream> int main() { std::cout << "elho\n"; } Compile and run: $ ./zig run -x c++ -lc++ standalone.c elho $ ./zig c++ -x c++ standalone.c -o standalone && ./standalone elho Fixes ziglang#10915
whoops, meant to comment in #14462. |
This commit adds support for "-x language" for a couple of hand-picked supported languages. There is no reason the list of supported languages to not grow (e.g. add "c-header"), but I'd like to keep it small at the start.
Alternative 1
I first tried to add a new type "Language", and then add that to the
CSourceFile
. But oh boy what a change it turns out to be. So I am keeping myself tied to FileExt and see what you folks think.Alternative 2
I tried adding
Language: ?[]const u8
toCSourceFile
. However, the language/ext, whatever we want to call it, still needs to be interpreted in the main loop: one kind of handling for source files, other kind of handling for everything else.Test case
standalone.c
Compile and run:
Fixes #10915