build: types and packages are mess #405

New issue

Closed

opened 2022-07-12 18:25:26 +00:00 by alichraghi · 5 comments

alichraghi commented

2022-07-12 18:25:26 +00:00

(Migrated from github.com)

the goal of this issue is try to find out a way to not repeat codes in sub-projects and also build files
for example same Options struct exist in ./build.zig and gpu/build.zig. or refAllDecls function (which is very useful for tests and we should consider to use it in other packages) has been declared twice in freetype and audio/soundio

the goal of this issue is try to find out a way to not repeat codes in sub-projects and also build files for example same `Options` struct exist in `./build.zig` and `gpu/build.zig`. or `refAllDecls` function (which is very useful for tests and we should consider to use it in other packages) has been declared twice in **freetype** and **audio/soundio**

PiergiorgioZagaria commented

2022-07-12 18:53:02 +00:00

(Migrated from github.com)

I think the reason for the code repetition was because we can't import from ../. For example we could have a build_utils.zig file with all the structs and functions commonly used in the build.zig files, but we wouldn't be able to import it.

Also, there is the fact that we are offering people the ability to use mach packages by themselves without adding all of mach. For example if someone wanted to use just mach-glfw it would still need that build_utils.zig.

I think the reason for the code repetition was because we can't import from `../`. For example we could have a `build_utils.zig` file with all the structs and functions commonly used in the `build.zig` files, but we wouldn't be able to import it. Also, there is the fact that we are offering people the ability to use mach packages by themselves without adding all of mach. For example if someone wanted to use just `mach-glfw` it would still need that `build_utils.zig`.

emidoots commented

2022-07-12 19:02:13 +00:00

(Migrated from github.com)

Yep what @PiergiorgioZagaria said is correct.

I will also say, copying a few hundred lines is often preferable over a dependency (repeating code is not a bad thing.) This is a non-issue from my viewpoint.

Have any issues been caused by this? (e.g. two copies actually becoming out of date and it being a problem)? If not, I'd suggest we just do nothing until that happens & then address only that instance of it.

Yep what @PiergiorgioZagaria said is correct. I will also say, copying a few hundred lines is often preferable over a dependency (repeating code is not a bad thing.) This is a non-issue from my viewpoint. Have any issues been caused by this? (e.g. two copies actually becoming out of date and it being a problem)? If not, I'd suggest we just do nothing until that happens & then address only that instance of it.

alichraghi commented

2022-07-13 06:51:44 +00:00

(Migrated from github.com)

Have any issues been caused by this?

when hacking on #396, i had to use @bitCast while passing the exact same Options struct to gpu.testStep
Mach is definitely going to get bigger, and with the increase of such problems, controlling code quality will become more difficult

hopefully zig's official package manager solves all those

> Have any issues been caused by this? when hacking on #396, i had to use `@bitCast` while passing the exact same `Options` struct to `gpu.testStep` Mach is definitely going to get bigger, and with the increase of such problems, controlling code quality will become more difficult hopefully zig's official package manager solves all those

emidoots commented

2022-07-17 16:49:51 +00:00

(Migrated from github.com)

I agree those bitcasts between package parameters are an issue 👍 But I think they're caused by us using symlinks to load packages, not because of code duplication