Since 99% of the native build is just building tensorflow, configuration should be handled in the same way (i.e. the configure script, or anything else). This is mentioned in #195, and clarified in the latest commit. Is there any reason that wouldn't work for you?

It's not that it's completely impossible to find out the practical information required to create a custom build, it's just that it would be incredibly easy to make finding this information convenient.

As a result, hundreds or thousands of individual users wouldn't need to spend time searching for and learning this trivia, which they'll probably never need again, just to accomplish the task of building the binaries for compute capabilities other than 3.5 and 7.0.

You don't have to go hunting for any information though, you just clone tensorflow and run the configuration script. The reason we (and tensorflow) delegate to that is any hard-coded paths we provide will be wrong more often than they are right, so the script tries its best to autodetect them. Plus a lot of the configuration has been moved to the bazelrc files in the latest tensorflow release, so there should be even less required configuration.

What exactly is so hard to find?

It is possible though to simply use the TF archive that Bazel downloads and unzips just before building TF Java, instead of cloning the repo.

I'm wondering if it would work to run the configure script from that unzipped archive during the Maven build directly, e.g. by passing a parameter like -Dnative.build.custom=true. I never tried running a blocking goal that requires user input in Maven though, is that possible?

Or we simply add a new script in the Java repo that invoke Bazel to download the archive and run configure on it, bypassing our default .bazelrc config.

Or we simply add a new script in the Java repo that invoke Bazel to download the archive and run configure on it, bypassing our default .bazelrc config.

I like this option much more. It would just be our own version of the configure script.