Repository navigation
Exzessive size due to bundled dependencies #35
Description
Activity
I think the lazy dependency solution in #37 is going to be a huge improvement on this front. Independently of this change, we should also consider if there's a way to improve the situation even when users do want all of the headers to be provided by the build system.
Right now we're pulling in all of these projects in their entireties just to get the headers. This means that even though we don't need them, we're also getting all the cpp files, any test data, etc.
One solution is to package up the headers we need in their own repo. I don't think we should have to do this though, and it's painful for users to audit.
We're already considering adding a flag to build.zig.zon that filters which files are considered part of a package for the purposes of generating the package's hash, eg to exclude symlinks from the hash. I think we should probably design this feature to support this use case as well.
That is to say, we should be able to specify that we only want the h files, and then as a result fetch only the h files, or when that's not possible fetch everything and then delete everything except for the h files. This would allow even users who want all the headers to avoid storing all of this extra data.
Right now we're pulling in all of these projects in their entireties just to get the headers. This means that even though we don't need them, we're also getting all the cpp files, any test data, etc.
One solution is to package up the headers we need in their own repo. I don't think we should have to do this though, and it's painful for users to audit.yes agree 100%! this would make lean packaging a lot easier and let us use non minimalistic c-ish projects without maintaining pesky stripped forks that are hard to update.
We're already considering adding a flag to build.zig.zon that filters which files are considered part of a package for the purposes of generating the package's hash, eg to exclude symlinks from the hash. I think we should probably design this feature to support this use case as well.
please do! will it be rather something core will implement or accepted from the "common folk"?
soo.... if i remember correctly source size of sdl3 is around 33M which is already a lot
i honestly was a bit shocked when i checked why dvui zig-pkg size ballooned again in size since we switched... with the other backend dependencies that also bundle their system deps (i am also trying to fix that) we are nearing 1 G of deps (in every repo!) which just shows that thats an unsustainable way going forward
why are we bundling all that junk here?
if someones cross compiling they should just build them a sysroot and supply explicit paths right?