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

ability to specify the file path basename of build artifacts (including extension) #2279

Open
tiehuis opened this issue Apr 15, 2019 · 4 comments
Labels
accepted This proposal is planned. proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Milestone

Comments

@tiehuis
Copy link
Member

tiehuis commented Apr 15, 2019

Accepted Proposal


For example zig build-exe t.zig --emit llvm-ir --name output generates the output file output.ll when it should use only the name field and not add an extension. It is expected to generate output bit code to output.

This is the same for zig build-exe t.zig --emit asm --name output, which generates output.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.

@tiehuis tiehuis added bug Observed behavior contradicts documented or intended behavior contributor friendly This issue is limited in scope and/or knowledge of Zig internals. labels Apr 15, 2019
@daurnimator
Copy link
Collaborator

See also #2231

@andrewrk andrewrk added this to the 0.5.0 milestone Apr 15, 2019
@andrewrk andrewrk added proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. and removed bug Observed behavior contradicts documented or intended behavior contributor friendly This issue is limited in scope and/or knowledge of Zig internals. labels Apr 15, 2019
@andrewrk
Copy link
Member

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.

@tiehuis
Copy link
Member Author

tiehuis commented Apr 16, 2019

Ahh, I overlooked the case of build-lib and related. I'll have a think and add an alternative to account for the multiple artifact case. I do feel like it is valuable to have name be adhered to completely and not implicitly changed by other flags, however.

@andrewrk
Copy link
Member

andrewrk commented Jan 7, 2020

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 --output-dir. In this directory can be any number of things, which can be enabled or disabled. For example:

  • -femit-docs and -fno-emit-docs toggle outputting generated documentation
  • -femit-bin and -fno-emit-bin toggle outputting object/lib/executable

--emit is deprecated; all 3 of the choices should be separate togglable things to output (asm, llvm-ir, machine code). One thing we could do to address this issue is to have the standard "emit" options all have a uniform way of overriding the file path basename. By default this would be the --name + appropriate extension, but could be overridden.

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.

@andrewrk andrewrk changed the title --name field should not add file type suffixes for specific output types ability to specify the file path basename of build artifacts (including extension) Jan 7, 2020
@andrewrk andrewrk added the accepted This proposal is planned. label Jan 7, 2020
@andrewrk andrewrk modified the milestones: 0.6.0, 0.7.0 Jan 7, 2020
@andrewrk andrewrk modified the milestones: 0.7.0, 0.8.0 Oct 9, 2020
@andrewrk andrewrk modified the milestones: 0.8.0, 0.9.0 May 19, 2021
@andrewrk andrewrk modified the milestones: 0.9.0, 0.10.0 Nov 20, 2021
@andrewrk andrewrk modified the milestones: 0.10.0, 0.11.0 Apr 16, 2022
@andrewrk andrewrk modified the milestones: 0.11.0, 0.12.0 Apr 9, 2023
@andrewrk andrewrk removed this from the 0.13.0 milestone Jun 29, 2023
@andrewrk andrewrk added this to the 0.12.0 milestone Jun 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepted This proposal is planned. proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Projects
None yet
Development

No branches or pull requests

3 participants