-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
ability to specify the file path basename of build artifacts (including extension) #2279
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
Comments
See also #2231 |
Hold on for a second, it actually is intentional. (Though the fact that it appears unintentional is problematic and worth addressing) So the deal is that with a several of the build options, zig produces more than one build artifact. For example for a libraries and objects, zig produces libfoo.a and foo.h. For dynamic libraries, the name + the major version is used as the SONAME. I think there are one or two more examples. Point being we have the concept of the "name" of the thing being built independent from the "output file". If --name is changed to mean output file, then we have to solve the problem of multiple output files and places that use the concept of the name. |
Ahh, I overlooked the case of |
We're moving to a convention where building something has an "artifact directory" which can be in the cache or it can be provided by
This way we can still use artifact directories, making this strategy cache friendly, but still have the user have a way to decide the filename. |
--name
field should not add file type suffixes for specific output types
Uh oh!
There was an error while loading. Please reload this page.
Accepted Proposal
For example
zig build-exe t.zig --emit llvm-ir --name output
generates the output fileoutput.ll
when it should use only the name field and not add an extension. It is expected to generate output bit code tooutput
.This is the same for
zig build-exe t.zig --emit asm --name output
, which generatesoutput.s
.Marking as a bug since I don't think this is the intended behavior.
This issue came up here: compiler-explorer/compiler-explorer#1328.
The text was updated successfully, but these errors were encountered: