build: Don't install libraries #232

New issue

Closed

opened 2022-04-18 12:24:23 +00:00 by silversquirl · 2 comments

silversquirl commented

2022-04-18 12:24:23 +00:00

(Migrated from github.com)

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.

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

2022-04-18 16:34:40 +00:00

(Migrated from github.com)

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.

> 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 `LibExeObjStep`s 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.

emidoots commented

2022-04-18 17:37:48 +00:00

(Migrated from github.com)

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.

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.

👍 1