Bazel memiliki dukungan yang canggih untuk membuat model platform dan toolchain untuk multi-arsitektur dan build yang dikompilasi silang.
Halaman ini merangkum status dukungan ini.
Lihat juga:
Status
C++
Aturan C++ menggunakan platform untuk memilih toolchain saat
--incompatible_enable_cc_toolchain_resolution
ditetapkan.
Artinya, Anda dapat mengonfigurasi project C++ dengan:
bazel build //:my_cpp_project --platforms=//:myplatform
alih-alih yang lama:
bazel build //:my_cpp_project` --cpu=... --crosstool_top=... --compiler=...
Ini akan diaktifkan secara default pada Bazel 7.0 (#7260).
Untuk menguji project C++ Anda dengan platform, lihat Memigrasikan Project Anda dan Mengonfigurasi toolchain C++.
Java
Aturan Java menggunakan platform untuk memilih toolchain.
Tindakan ini menggantikan tanda lama --java_toolchain
, --host_java_toolchain
,
--javabase
, dan --host_javabase
.
Lihat Java dan Bazel untuk mengetahui detailnya.
Android
Aturan Android menggunakan platform untuk memilih toolchain saat
--incompatible_enable_android_toolchain_resolution
ditetapkan.
Ini berarti Anda dapat mengonfigurasi project Android dengan:
bazel build //:my_android_project --android_platforms=//:my_android_platform
bukan dengan tanda lama seperti --android_crosstool_top
, --android_cpu
,
dan --fat_apk_cpu
.
Ini akan diaktifkan secara default pada Bazel 7.0 (#16285).
Untuk menguji project Android Anda dengan platform, lihat Memigrasikan Project Anda.
Apel
Aturan Apple tidak mendukung platform dan belum dijadwalkan untuk mendapatkan dukungan.
Anda masih dapat menggunakan API platform dengan build Apple (misalnya, saat membangun aplikasi dengan campuran aturan Apple dan C++ murni) dengan pemetaan platform.
Bahasa lainnya
- Aturan Go mendukung sepenuhnya platform
- Aturan Rust sepenuhnya mendukung platform.
Jika Anda memiliki kumpulan aturan bahasa, lihat Memigrasikan kumpulan aturan untuk menambahkan dukungan.
Latar belakang
Platform dan toolchain diperkenalkan untuk menstandarkan cara project software menargetkan berbagai arsitektur dan kompilasi silang.
Hal ini
terinspirasi
oleh pengamatan bahwa pengelola bahasa telah melakukan hal ini secara ad
hoc dan tidak kompatibel. Misalnya, aturan C++ menggunakan --cpu
dan
--crosstool_top
untuk mendeklarasikan CPU target dan toolchain. Tak satu pun dari alat ini yang
memodelkan "platform" dengan benar. Hal ini menghasilkan build yang tidak nyaman dan salah.
Java, Android, dan bahasa lain mengembangkan flagnya sendiri untuk tujuan serupa, dan tidak ada yang saling beroperasi satu sama lain. Hal ini membuat build lintas bahasa membingungkan dan rumit.
Bazel ditujukan untuk project multiplatform berskala besar dan multibahasa. Hal ini menuntut dukungan yang lebih berprinsip untuk konsep ini, termasuk API standar yang jelas.
Perlunya migrasi
Upgrade ke API yang baru memerlukan dua upaya: merilis API dan mengupgrade logika aturan untuk menggunakannya.
Yang pertama sudah selesai, tetapi yang kedua sedang berlangsung. Langkah ini terdiri dari memastikan
platform dan toolchain khusus bahasa ditentukan, logika bahasa membaca
toolchain melalui API baru, bukan flag lama seperti --crosstool_top
, dan
config_setting
memilih di API baru, bukan flag lama.
Pekerjaan ini mudah tetapi membutuhkan upaya berbeda untuk setiap bahasa, ditambah peringatan yang adil bagi pemilik project untuk menguji perubahan mendatang.
Itulah sebabnya migrasi ini bersifat berkelanjutan.
Sasaran
Migrasi ini selesai jika semua project dibuat dengan formulir:
bazel build //:myproject --platforms=//:myplatform
Ini menyiratkan:
- Aturan project Anda memilih toolchain yang tepat untuk
//:myplatform
. - Dependensi project Anda memilih toolchain yang tepat untuk
//:myplatform
. //:myplatform
merujuk ke deklarasi umumCPU
,OS
, dan properti generik lain yang tidak bergantung pada bahasa- Semua
select()
yang relevan cocok dengan//:myplatform
. //:myplatform
ditentukan di tempat yang jelas dan dapat diakses: di repositori project Anda jika platform tersebut bersifat unik untuk project Anda, atau di tempat umum yang dapat ditemukan semua project yang menggunakannya
Tanda lama seperti --cpu
, --crosstool_top
, dan --fat_apk_cpu
tidak akan
digunakan lagi dan dihapus segera setelah aman untuk melakukannya.
Pada akhirnya, ini akan menjadi cara satu-satunya untuk mengonfigurasi arsitektur.
Memigrasikan project Anda
Jika Anda mem-build dengan bahasa yang mendukung platform, build Anda seharusnya sudah berfungsi dengan pemanggilan seperti:
bazel build //:myproject --platforms=//:myplatform
Lihat Status dan dokumentasi bahasa Anda untuk mengetahui detail selengkapnya.
Jika sebuah bahasa memerlukan flag untuk mengaktifkan dukungan platform, Anda juga harus menyetel flag tersebut. Lihat Status untuk mengetahui detailnya.
Agar project dapat dibuat, Anda harus memeriksa hal-hal berikut:
//:myplatform
harus ada. Umumnya pemilik project bertanggung jawab untuk menentukan platform karena project yang berbeda menargetkan mesin yang berbeda. Lihat Platform default.Toolchain yang ingin Anda gunakan harus ada. Jika menggunakan toolchain stok, pemilik bahasa harus menyertakan petunjuk cara mendaftarkannya. Jika menulis toolchain kustom, Anda harus register di
WORKSPACE
atau dengan--extra_toolchains
.select()
dan transisi konfigurasi harus diselesaikan dengan benar. Lihat select() dan Transitions.Jika build Anda menggabungkan bahasa yang mendukung dan tidak mendukung platform, Anda mungkin memerlukan pemetaan platform untuk membantu bahasa lama berfungsi dengan API baru. Lihat Pemetaan platform untuk mengetahui detailnya.
Jika Anda masih mengalami masalah, hubungi dukungan.
Platform default
Pemilik project harus menentukan
platform eksplisit untuk menjelaskan arsitektur
yang ingin mereka bangun. Peristiwa ini kemudian dipicu dengan --platforms
.
Jika --platforms
tidak disetel, Bazel akan ditetapkan secara default ke platform
yang mewakili
mesin build lokal. Kode ini dihasilkan otomatis pada @platforms//host
(dialiaskan sebagai
@bazel_tools//tools:host_platform
),
jadi tidak perlu menentukannya secara eksplisit. Objek ini memetakan OS
dan CPU
komputer lokal dengan constraint_value
yang dideklarasikan dalam
@platforms
.
select()
Project dapat select()
pada
target constraint_value
, tetapi tidak dapat menyelesaikan
platform. Hal ini disengaja sehingga select()
mendukung sebanyak mungkin
mesin. Library dengan sumber khusus ARM
akan mendukung semua
mesin yang didukung ARM
kecuali jika ada alasan untuk lebih spesifik.
Untuk memilih satu atau beberapa constraint_value
, gunakan:
config_setting(
name = "is_arm",
constraint_values = [
"@platforms//cpu:arm",
],
)
Tindakan ini sama dengan memilih secara tradisional di --cpu
:
config_setting(
name = "is_arm",
values = {
"cpu": "arm",
},
)
Lihat detail selengkapnya di sini.
select
di --cpu
, --crosstool_top
, dll. tidak memahami --platforms
.
Saat memigrasikan project ke platform, Anda harus mengonversinya ke
constraint_values
atau menggunakan pemetaan platform untuk mendukung
kedua gaya selama migrasi.
Transisi
Transisi Starlark mengubah
tombol di grafik build ke bawah. Jika project Anda menggunakan transisi yang menetapkan --cpu
, --crossstool_top
, atau tanda lama lainnya, aturan yang bertuliskan --platforms
tidak akan melihat perubahan ini.
Saat memigrasikan project ke platform, Anda harus mengonversi perubahan seperti
return { "//command_line_option:cpu": "arm" }
ke return {
"//command_line_option:platforms": "//:my_arm_platform" }
atau menggunakan pemetaan
platform untuk mendukung kedua gaya selama migrasi.
Memigrasikan kumpulan aturan
Jika memiliki kumpulan aturan dan ingin mendukung platform, Anda harus:
Buat logika aturan me-resolve toolchain dengan API toolchain. Lihat toolchain API (
ctx.toolchains
).Opsional: tentukan flag
--incompatible_enable_platforms_for_my_language
sehingga logika aturan akan me-resolve toolchain secara bergantian melalui API baru atau flag lama seperti--crosstool_top
selama pengujian migrasi.Menentukan properti relevan yang membentuk komponen platform. Lihat Properti platform umum
Tentukan toolchain standar dan buat agar dapat diakses oleh pengguna melalui petunjuk pendaftaran aturan Anda (detail)
Pastikan
select()
dan transisi konfigurasi mendukung platform. Inilah tantangan terbesar. Hal ini sangat sulit untuk project multibahasa (yang mungkin gagal jika semua bahasa tidak dapat membaca--platforms
).
Jika perlu menggabungkan aturan yang tidak mendukung platform, Anda mungkin memerlukan pemetaan platform untuk menjembatani kesenjangan.
Properti platform umum
Properti platform lintas bahasa yang umum seperti OS
dan CPU
harus
dideklarasikan di @platforms
.
Hal ini mendorong aktivitas berbagi, standardisasi, dan kompatibilitas lintas bahasa.
Properti yang unik untuk aturan Anda harus dideklarasikan di repositori aturan Anda. Hal ini memungkinkan Anda mempertahankan kepemilikan yang jelas atas konsep tertentu yang menjadi tanggung jawab aturan Anda.
Jika aturan Anda menggunakan OS atau CPU untuk tujuan khusus, hal tersebut harus dideklarasikan dalam
repo aturan Anda vs.
@platforms
.
Pemetaan platform
Pemetaan platform adalah API sementara yang memungkinkan logika berbasis platform tercampur dengan logika lama dalam build yang sama. Ini adalah alat tumpul yang hanya dimaksudkan untuk memuluskan inkompatibilitas dengan jangka waktu migrasi yang berbeda.
Pemetaan platform adalah peta platform()
ke
kumpulan tanda lama yang sesuai atau sebaliknya. Contoh:
platforms:
# Maps "--platforms=//platforms:ios" to "--cpu=ios_x86_64 --apple_platform_type=ios".
//platforms:ios
--cpu=ios_x86_64
--apple_platform_type=ios
flags:
# Maps "--cpu=ios_x86_64 --apple_platform_type=ios" to "--platforms=//platforms:ios".
--cpu=ios_x86_64
--apple_platform_type=ios
//platforms:ios
# Maps "--cpu=darwin_x86_64 --apple_platform_type=macos" to "//platform:macos".
--cpu=darwin_x86_64
--apple_platform_type=macos
//platforms:macos
Bazel menggunakannya untuk menjamin semua setelan, baik yang berbasis platform maupun lama, diterapkan secara konsisten di seluruh build, termasuk melalui transisi.
Secara default, Bazel membaca pemetaan dari file platform_mappings
di root ruang kerja Anda. Anda juga dapat menetapkan --platform_mappings=//:my_custom_mapping
.
Lihat desain pemetaan platform untuk mengetahui detailnya.
Peninjauan API
platform
adalah kumpulan target constraint_value
:
platform(
name = "myplatform",
constraint_values = [
"@platforms//os:linux",
"@platforms//cpu:arm",
],
)
constraint_value
adalah properti
mesin. Nilai "jenis" yang sama dikelompokkan dalam constraint_setting
umum:
constraint_setting(name = "os")
constraint_value(
name = "linux",
constraint_setting = ":os",
)
constraint_value(
name = "mac",
constraint_setting = ":os",
)
toolchain
adalah aturan Starlark. Atributnya mendeklarasikan alat bahasa (seperti compiler =
"//mytoolchain:custom_gcc"
). Penyedianya meneruskan informasi ini ke aturan yang perlu di-build dengan alat tersebut.
Toolchain mendeklarasikan constraint_value
mesin yang dapat mereka
targetkan
(target_compatible_with = ["@platforms//os:linux"]
) dan mesin yang dapat
dijalankan
(exec_compatible_with = ["@platforms//os:mac"]
).
Saat mem-build $ bazel build //:myproject --platforms=//:myplatform
, Bazel
akan otomatis memilih toolchain yang dapat dijalankan di mesin build dan
biner build untuk //:myplatform
. Hal ini dikenal sebagai resolusi toolchain.
Set toolchain yang tersedia dapat didaftarkan di WORKSPACE
dengan
register_toolchains
atau di
command line dengan --extra_toolchains
.
Untuk informasi selengkapnya lihat di sini.
Pertanyaan
Untuk dukungan umum dan pertanyaan tentang linimasa migrasi, hubungi bazel-discuss atau pemilik aturan yang sesuai.
Untuk diskusi tentang desain dan evolusi API platform/toolchain, hubungi bazel-dev.