zstd: Add zstd_cli cc_binary

[afq984]

No description provided.

[bazel-io]

Hello @bazelbuild/bcr-maintainers, modules without existing maintainers (zstd) have been updated in this PR. Please review the changes.

[afq984]

This should be the minimal changes to allow building the zstd binary.

However I'd like to have our BUILD.bazel files follow the zstd upstream BUCK files in structure so we don't deviate too much (say, @zstd//programs:zstd instead of @zstd//:zstd_cli), at the cost of bumping the compatibility level. Thoughts?

cc @jondo2010 @lalten as you contributed previous versions

[fmeum]

Bumping the compatibility level could be quite disruptive to users of the library. Could you leave an alias in place instead?

[afq984]

I'm fine with aliasing

[lalten]

the diff of the BUILD is

3c3
< index 00000000..7fca1671
---
> index 00000000..f0a5da7e
6c6
< @@ -0,0 +1,127 @@
---
> @@ -0,0 +1,148 @@
73a74,94
> +)
> +
> +cc_binary(
> +    name = "zstd_cli",
> +    srcs = glob(
> +        include = [
> +            "programs/*.c",
> +            "programs/*.h",
> +        ],
> +        exclude = [
> +            "programs/datagen.c",
> +            "programs/datagen.h",
> +            "programs/platform.h",
> +            "programs/util.h",
> +        ],
> +    ),
> +    deps = [
> +        ":datagen",
> +        ":util",
> +        ":zstd",
> +    ],

It really is a shortcoming of the separate version dirs in the BCR that you can't easily see what's changed between versions :(

[lalten]

Why do you need to bump the compatibility level to add @zstd//programs:zstd if you keep @zstd//:zstd the same? One easy way would be to just patch in a separate BUILD in the programs dir

[afq984]

#1730 (comment) If you mean only create the @zstd//programs:zstd in @zstd//programs and keep the rest as-is, the asymmetry of @zstd//:datagen_cli and @zstd//programs:zstd bugs me a bit. If you mean following upstream BUCK files, move everything to sub-packages and leave top level aliases, then yeah I agree it should work.

So far it seems like bumping the compatibility level causes more trouble then it's worth (maintenance, hiding @zstd//:*_sources filegroups, etc), so I'll stop pursuing bumping.

[afq984]

@fmeum could you help review this PR at its current state (no structure or any compatibility level changes)? Thanks!

Require module maintainers' approval for newly pushed changes.