Move Config Srcs into build_srcs.bzl

[mcr229]

Light refactoring to move config srcs into build_srcs.bzl

[mcr229]

@dsharletg

[dsharlet]

Nit: I think this should be MICROKERNEL_CONFIG_SRCS for consistency with e.g. MICROKERNEL_DEPS, MICROKERNEL_HDRS.

[mcr229]

yea that makes sense.

[dsharlet]

@gonnet FYI. Motivation here is, @mcr229 and team were using this variable in their build system. We deleted it because it was unused (in this repo). I think the best way to ensure it doesn't get deleted is to use it.

[mcr229]

Seems like the issue was that src/pack-lh.cc actually uses the unary_elementwise_config and reduce_config. So i kept those around and but those as deps for pack_lh. I removed all others and joined them into microkernel_configs.

@gonnet @dsharlet

[dsharlet]

Is reduce-config.c and unary-elementwise-config.c getting compiled twice now?

Can src/pack-lh.c just depend on all the configs, rather than treating the reduce and unary elementwise configs as "special"?

[gonnet]

That won't work because pack-lh-config, which is also in this target, depends on pack-lh, and that would cause a circular dependency.

[gonnet]

What is the purpose of removing the granular targets in src/configs/BUILD?

I'm asking because I only recently split these out because it's best practices to have as granular targets as possible (see e.g. here).

[dsharlet]

I've sent #8664 which should eliminate the special case requirements of pack-lh, which would enable this PR to work as it was originally sent.

If sharing the BUILD becomes easier due to this change (a single BUILD target with a variable for the config srcs), then I don't think we should worry about bazel's guidelines @mcr229.

[gonnet]

@mcr229 I'm still confused about the intent of this change. If you need the list of config files, it's just the source files in XNNPACK/src/configs/.

The granular targets were part of an ongoing larger refactoring trying to put things in specific subdirectories to avoid having to have lists of sources (subgraph and operators were going to be next, but blocked on some dependency issues).

[mcr229]

@gonnet I didn't know that separating these build targets was an active effort. Honestly the level of separation of all MICROKERNEL_CONFIG srcs living in src/configs, all OPERATOR_SRCS living in src/operators, etc. makes sense and that level of organization could be leveraged by our build system to scrape the srcs from the appropriate directory. I'm ok with dropping this PR if that is the intent.

[gonnet]

@mcr229 That is fortunately almost already the current state, and I have an open Issue to clean things up. If it makes your build process simpler and/or easier to manage, I can prioritize wrapping up this work and get your feedback on the changes.