hexops / mach

zig game engine & graphics toolkit
https://machengine.org
Other
3.37k stars 160 forks source link

build: Don't install libraries #232

Closed silversquirl closed 2 years ago

silversquirl commented 2 years ago

Currently, all libraries produced by Mach are installed to the output prefix. This is undesirable as Zig's build system can be used to produce packages, or to install globally to the system, and Mach static libs are simply compilation side-products, not necessarily things wanted in the installation.

If building Dawn for non-Zig use is a supported usecase, I would suggest having a separate API for this - the current one doesn't really support it well anyway.

On a related note, mach/gpu/build.zig and mach/build.zig also build static libraries for some reason? Not sure why that is; they probably shouldn't since they're just Zig packages and don't expose C APIs.

Luexa commented 2 years ago

Currently, all libraries produced by Mach are installed to the output prefix. This is undesirable as Zig's build system can be used to produce packages, or to install globally to the system, and Mach static libs are simply compilation side-products, not necessarily things wanted in the installation.

Oh yeah, I meant to post something about this but didn't have the time earlier. Installing should never be done automatically; instead the LibExeObjStep should be exposed somewhere so the user can invoke .install() if they wish.

If building Dawn for non-Zig use is a supported usecase, I would suggest having a separate API for this - the current one doesn't really support it well anyway.

On a related note, mach/gpu/build.zig and mach/build.zig also build static libraries for some reason? Not sure why that is; they probably shouldn't since they're just Zig packages and don't expose C APIs.

Yup, there is no canonical way to link to the libraries as their LibExeObjSteps are local variables that are never returned. This, in turn, exacerbates the problem of polluting the build root without providing any functionality to the user. It does not make much sense to create and install a new static library when user just wants to link an existing static library to their existing build step.

slimsag commented 2 years ago

Thanks for filing this, and for reaching out earlier about the same issue @Luexa !

I removed the unused static libraries from mach/gpu/build.zig and mach/build.zig in #220

the LibExeObjStep should be exposed somewhere so the user can invoke .install() if they wish.

Makes sense to me, thanks for that idea!

If building Dawn for non-Zig use is a supported usecase, I would suggest having a separate API for this - the current one doesn't really support it well anyway.

It is indeed a supported use case, but currently only to the extent that zig build -Ddawn-from-source=true in the mach/gpu-dawn directory should produce and install a static libdawn.a for you (we also use this to create the binary release archives at https://github.com/hexops/mach-gpu-dawn/releases/tag/release-1005a82 )

I agree that gpu_dawn.link(...) should not .install() it if you are just consuming the library, though.