Ninja: Mendukung pengaturan verbositas melalui lingkungan

Saya pikir dalam kasus seperti ini Anda dapat membuat skrip Shell untuk mematuhi variabel lingkungan Anda. Kalau tidak, saya dapat memikirkan lingkungan yang setara di mana seseorang ingin VERBOSE=1 untuk mengontrol verbositas program selain Ninja.

Saya pikir dalam kasus seperti ini Anda dapat membuat skrip Shell untuk mematuhi variabel lingkungan Anda.

Variabel lingkungan ini untuk ninja, jadi bagaimana mereka akan dipatuhi jika ninja tidak mengenalinya?

Selain itu, tidak selalu layak, atau masuk akal, untuk memodifikasi baris perintah alat dalam skrip karena mungkin jumlahnya terlalu banyak. Apa yang Anda sarankan adalah setiap skrip mengadopsi cara unik untuk menyesuaikan flag yang diteruskan ke perintah, yang juga tidak masuk akal.

Saya telah membaca PR dan masalah lain yang terkait dengan situasi ini dan tidak menemukan jawaban yang dipikirkan dengan baik. Dalam setiap kasus, diasumsikan bahwa pengguna memiliki kontrol langsung atas di mana dan bagaimana ninja dijalankan atau bahkan dalam posisi untuk melakukan sesuatu secara realistis, terutama ketika sistem konfigurasi menghasilkan skrip ninja.build sebagai bagian dari pipa.

Variabel lingkungan ini untuk ninja, jadi bagaimana mereka akan dipatuhi jika ninja tidak mengenalinya?

Script akan mengenali mereka dan meneruskan misalnya -v ke ninja.

Jadi seperti yang saya prediksi, Anda mengharapkan setiap skrip, atau bahkan hal seperti skrip untuk mengkodekan rangkaian logikanya sendiri untuk memberikan opsi kepada ninja. Itu tidak masuk akal sama sekali.

Tidak, Anda hanya perlu satu skrip untuk melakukan itu, yang Anda beri nama ninja dan letakkan di PATH sebelum ninja yang sebenarnya dapat dieksekusi.

Saya pikir ini sudah tercakup dalam banyak laporan masalah lainnya? Itu juga tidak masuk akal karena sekarang mulai mempengaruhi reproduktifitas membangun saluran pipa di mana lingkungan layak untuk dilacak. Itu juga mengasumsikan orang memiliki kemampuan untuk melakukan apa yang Anda sarankan (pikirkan aman PATH ).

Itu juga tidak masuk akal karena sekarang mulai mempengaruhi reproduktifitas membangun saluran pipa di mana lingkungan layak untuk dilacak.

Anda akan memiliki skrip Anda selalu di sana, kemudian Anda dapat melacak VERBOSE seperti yang Anda lakukan jika ninja sendiri yang menanganinya.

berpikir aman PATH

Bagaimana apanya?

Saya tidak tertarik pada VERBOSE , saya pikir saran lain untuk mengekspos bendera melalui NINJAFLAGS lebih tepat seperti yang disarankan dalam banyak masalah lain tentang topik ini.

Sekali lagi, ini adalah permintaan yang tidak masuk akal ketika Anda mengelola ratusan paket, beberapa di antaranya menggunakan cmake untuk menghasilkan skrip ninja build. Membuat pembungkus yang tidak perlu untuk bertindak sebagai ketergantungan terlalu terlibat ketika sistem tradisional seperti make (dengan Makefile s yang dibuat atau ditulis dengan benar) terus menghormati tidak hanya lingkungan de facto seperti CFLAGS , CXXFLAGS , LDFLAGS , dll. tetapi juga MAKEFLAGS mana banyak dari kita akan menetapkan sesuatu ke efek -j$(nproc) .

Ini sekali lagi menjadi gagasan tentang jalan yang aman; sistem seperti sudo dan skrip build/CI akan menyetel PATH ke default yang diketahui baik untuk menghindari potensi pencemaran build yang biasanya juga didukung oleh chroot yang bersih.

beberapa di antaranya menggunakan cmake untuk menghasilkan skrip ninja build.

Saya tidak melihat bagaimana ini mengubah apa pun?

Ini sekali lagi menjadi gagasan tentang jalan yang aman; sistem seperti sudo dan skrip build/CI akan menyetel PATH ke default yang diketahui baik untuk menghindari potensi pencemaran build yang biasanya juga didukung oleh chroot yang bersih.

Dalam hal ini Anda dapat menghindari modifikasi PATH dengan mengganti nama biner ninja dan meletakkan skrip di tempatnya.

Dan sekitar kita pergi

Dalam hal ini Anda dapat menghindari modifikasi PATH dengan mengganti nama biner ninja dan meletakkan skrip di tempatnya.

Ini sangat tidak pantas untuk disarankan.

Pengguna tidak boleh main-main dengan binari tingkat sistem.

Ini tidak sesuai untuk sistem multi-pengguna untuk biner tingkat sistem diganti namanya dan diganti dengan skrip.

Saya akan mengatakannya lagi sebagai catatan: Saya memelihara sistem pembangunan yang dipesan lebih dahulu untuk tim pengembangan C++, ini mengkompilasi beberapa juta baris kode C++. Dulu melakukan banyak hal secara langsung, tetapi sekarang menghasilkan file ninja, dan semuanya bahagia. Jadi saya memiliki beberapa petunjuk untuk digosok ketika saya membicarakan hal ini.

Yang saya inginkan: Agar biner ninja mengenali satu variabel lingkungan yang menetapkan berbagai default, termasuk verbositas dan semacamnya.

Apa yang dapat saya terima: Ninja merespons beberapa variabel lingkungan.

Apa yang tidak dapat diterima: Perlu menulis skrip pembungkus.

Mengapa itu tidak dapat diterima: Saat menggunakan Windows, itu akan berfungsi dengan baik, saya kira. Tapi itu tidak dapat diterima di Linux, karena kami mengandalkan paket ninja sistem untuk menyediakan fungsionalitas. Jadi ketika menerapkan ke sistem Linux, saran Anda di sini adalah "Oh, ganti nama paket ninja level sistem, dan ganti dengan skrip" meneriakkan masalah keamanan, dan masalah pemeliharaan. Antara lain, sekarang saya harus menjaga sistem setiap kali paket ninja diperbarui oleh manajer paket sistem.

Ini bukan fitur yang berisiko untuk ditambahkan ke program. Tugas Ninja bukanlah untuk melindungi pengguna dari diri mereka sendiri. Jika pengguna entah bagaimana berhasil mengacaukannya, itu terserah mereka.

Kemungkinan menambahkan fitur seperti ini ke Ninja memperlambat Ninja lebih dari beberapa mikro detik sangat rendah sehingga tidak ada, tetapi proposal Anda adalah kami menggunakan skrip pembungkus, yang melibatkan mengeksekusi juru skrip setiap kali ninja diluncurkan, yang jauh dan jauh lebih banyak daripada beberapa perbandingan string dalam biner yang sudah dieksekusi.

Jadi ketika menerapkan ke sistem Linux, saran Anda di sini adalah "Oh, ganti nama paket ninja level sistem, dan ganti dengan skrip" meneriakkan masalah keamanan, dan masalah pemeliharaan.

Tidak, ketika menyebarkan ke Linux, saran saya adalah memasukkan skrip ke /usr/local/bin .

Saya tidak memiliki direktori itu di mesin linux saya, rupanya.

Saya tidak dapat menemukan referensi untuk itu dalam standar hierarki sistem file http://www.pathname.com/fhs/pub/fhs-2.3.pdf

Saya memang menemukan referensi ke /usr/local/sbin di FHS, mungkin itu yang Anda maksud? Tampaknya aneh menggunakan folder "sbin" untuk ini.

Agaknya, /usr/local/bin seharusnya berada di PATH sebelum /usr/bin dan lainnya.

Namun, bukan itu yang Anda katakan. Anda mengatakan ini:

Dalam hal ini Anda dapat menghindari modifikasi PATH dengan mengganti nama biner ninja dan meletakkan skrip di tempatnya.

Dan itu saran yang buruk, penuh dengan masalah keamanan dan pemeliharaan berkelanjutan.

Menempatkan skrip di direktori seluruh sistem yang selalu disertakan sebelum yang lainnya adalah cara yang lebih baik untuk melakukannya daripada mengganti nama biner dan meletakkan skrip di tempatnya.

Namun demikian, saya belum melihat penjelasan mengapa kami tidak hanya memasukkan ini ke dalam ninja itu sendiri, yang konsisten, tidak menambahkan banyak overhead dari memanggil skrip dan/atau "setiap orang perlu menulis skrip sendiri sekarang", dan menunjuk ke pedoman untuk proyek ninja seperti yang didokumentasikan di sini di github.

Implementasi ulang bahasa build Ninja independen https://github.com/michaelforney/samurai mendukung ini melalui variabel lingkungan SAMUFLAGS. Cukup gunakan samu di mana pun Anda menggunakan ninja, atau instal samu sebagai sistem Anda /usr/bin/ninja (beberapa distro linux memiliki opsi untuk menginstal implementasi yang bersaing ini sebagai default, atau hanya ninja).