Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to build XNNPACK by Bazel 6.5 #7720

Open
jfulem opened this issue Jan 27, 2025 · 2 comments
Open

How to build XNNPACK by Bazel 6.5 #7720

jfulem opened this issue Jan 27, 2025 · 2 comments

Comments

@jfulem
Copy link

jfulem commented Jan 27, 2025

When I run bazel build :XNNPACK or bazel build //... I get:

xnnpack/MODULE.bazel:38:16: name 'use_repo_rule' is not defined ERROR: Error computing the main repository mapping: error executing MODULE.bazel file for <root>

When I run bazel build --config windows_x86_64 :XNNPACK
I get: ERROR: Config value 'windows_x86_64' is not defined in any .rc file

So, how do I build XNNPACK by using bazel? By CMake, it's all clear.

Thank you very much.

@fbarchard
Copy link
Collaborator

Hi, thanks for the question. As you referred to Windows, thats something I'm learning myself.
From linux, I've used clangcl via lexan, which is --config=lexan_x86_64 and I've used wine or wine32 to test it.

But when building on Windows, as you say, cmake is easy.
Although I mistakenly did it wrong, calling scripts/build-local.sh and it works anyway.
But there is a .cmd script, which uses ninja but should be the same and gives an option for 32 bit x86.

I havent tried arm, but the 'local' approach works for me on riscv so i expect cmake on windows arm, for windows arm, would also work the same way.

For local builds using a default compiler

bazel build :all

That will be a 'fastbuild', and you can do optimized with

bazel build -c opt :all

So that should work on Window doing a local build for Windows, using Visual C.
There are setup instructions that need to be done once to set up bazel.

For cross builds to other platforms, there is a config. e,g, --config=android_x86_64
Config names are being made more consistent, so its usually the OS and CPU, and hopefully the cpus have the same 'x86_64' naming going forward.

@jfulem
Copy link
Author

jfulem commented Jan 30, 2025

Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants