Comments (5)
Only partially. Those fields aren't used in all the places you'd hope/expect compared to name
. There's also the issue that they include all the target-specific prefixes/suffixes, so you lose quite a bit of abstraction once you start mucking with them.
Another separate but related issue is that if the static library in my scenario has a different name on Windows (to avoid conflicting with the shared library's generated import library), the user of my library has to replicate the logic to pick the artifact name based on whether the target is Windows. Having a separate "artifact name" concept that is distinct from "application/library name" would solve that, too.
from zig.
They have the same name because I want them to end up as
libfoo.so
andlibfoo.a
.
std.Build.Dependency.artifact
returns a *std.Build.Step.Compile
, which has a field out_filename
(and out_lib_filename
).
I think you should be able to refer to them as "fooDynamic"
and "fooStatic"
, and then tweak these field values so they are still generated with the name you want.
I hope that helps, not sure if this fully addresses your use case though.
from zig.
Related: #18513 .
I suggested in Discord to separate creating a module/artifact and exporting it for the package manager in two different calls, which should fix this problem and make a nice simmetry with dep.module("...")
and dep.artifact("...")
calls in downstream consumers:
const mod = b.createModule(.{
.root_source_file = b.path("src/main.zig"),
.target = target,
.optimize = optimize,
});
mod.expose("main");
// In downstream: b.dependency(...).nodule("main")
const exe = b.addExecutable(.{ .name = "project", ... });
const lib = b.addExecutable(.{ name = "project", ... });
exe.expose("main-exe");
lib.expose("main-lib");
// In downstream: b.dependency(...).artifact(...);
Since this is a rare case, we can make Step.Compile.expose
to accept struct instead, with default field = null meaning "take name from the artifact itself", so that for common cases user do not need to repeat name of artifact twice.
from zig.
Would adding an output_name
optional field to addStaticLibrary
/addSharedLibrary
options and use it to construct the related Step.Compile
fields be a good solution to this?
from zig.
Would adding an
output_name
optional field toaddStaticLibrary
/addSharedLibrary
options and use it to construct the relatedStep.Compile
fields be a good solution to this?
That was more or less my initial suggestion in the Discord discussion. Having slept on it, though, I'm starting to warm to the idea of having an explicit gesture to "export" an artifact from the build script, just like how marking an artifact for installation is an explicit gesture. It feels more "Zig-y".
from zig.
Related Issues (20)
- fuzz testing: support Windows
- fuzzing: support more than one executable at once
- debug info audit - many virtual memory addresses have strange source locations
- `-OReleaseSafe` breaks fuzzing entry points feature; incorrect already-sorted assumption
- unreachable code paths need to be excluded from having coverage instrumentation
- more optimized and correct management of 8-bit PC counters
- fuzzer web interface: play a little jingle when it finds a bug!
- fuzzer web interface: ability to scroll to source locations that newly gain coverage HOT 1
- Ability to determine the file a module is in without complete knowledge of the compilations module dependency graph HOT 5
- --verbose-llvm-bc= compile option does not work when providing a file name
- ICE involving empty slice of anonymous struct type
- --unresolved-symbols seems not work for zig cc
- [Feature Request/Bug] Make MultiArrayList behave like normal ArrayList HOT 5
- compiler: remove unused struct fields HOT 7
- std.json: parsing: possibility for missing optional fields to not trigger an error HOT 2
- @alignOf() returns incorrect alignment for structs containing multiple SIMD vectors HOT 2
- Crash (likely undefined behavior) of `std.process.Child.run` in `ReleaseFast` mode only
- ICE: self-hosted generating an atom for an extern declaration
- translate-c misses an alignment cast in translated C code HOT 2
- proposal: change `zig fmt` to format lists of one item with spaces
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from zig.