Ninja: Jalur subninja relatif tidak menyelesaikan

Semua jalur relatif terhadap direktori build, bukan ke file yang berisi baris subninja.

Itu tidak masuk akal. Itu berarti generator harus _all_ mengimplementasikan beberapa cara untuk menambahkan awalan ke file, yang berarti mengubah perintah direktori kerja yang dijalankan (yang dapat mengubah maksud asli dari konfigurasi build tergantung pada cara generator/perintah dijalankan).

Lalu, apa kasus penggunaan yang kontras untuk subninja vs include ?

Subninja dengan jalur relatif ke file build akan berguna karena dependensi yang dikonfigurasi untuk berjalan di dalam direktori mereka sendiri dapat melakukannya tanpa harus mengubah jalurnya, tetapi masih dapat berkontribusi pada grafik ketergantungan dari konfigurasi ninja induk.

Fungsi include tidak akan dimodifikasi, dan akan bertindak persis seperti tindakan subninja selain nama aturan fakta yang sekarang berada di namespace gabungan (sesuai #921). Saat ini, subninja dan include pada dasarnya mencapai hal yang sama selain variabel pelingkupan dan nama aturan...

Idenya adalah generator menghasilkan semua file .ninja, sehingga mereka dapat menulis jalur relatif ke direktori build. Ini adalah ide yang menarik untuk menggabungkan file ninja yang dihasilkan oleh generator yang berbeda (sepertinya itu yang ingin Anda lakukan?), tetapi itu bukan sesuatu yang didukung saat ini.

Benar, perbedaan antara subninja dan include adalah bahwa yang pertama menambahkan ruang lingkup dan yang terakhir tidak. Kasus penggunaan untuk ini adalah ninja tingkat atas dapat menentukan aturan build umum seperti cc yang merujuk variabel seperti cflags , dan setiap subninja dapat menetapkan cflags ke apa yang sesuai untuk target itu, dan di sana bisa menjadi tindakan satu kali di sana. Untuk melihat contoh, Anda dapat menjalankan python misc/write_fake_manifests.py /tmp/foo` untuk menulis banyak file .ninja ke /tmp/foo yang menggunakan pola ini.

Itu masuk akal, meskipun saya masih tidak melihat banyak manfaat (selain ruang lingkup).

Merupakan ide yang menarik untuk menggabungkan file ninja yang dihasilkan oleh generator yang berbeda (sepertinya itu yang ingin Anda lakukan?)

Tepat. Mampu memasukkan Ninja itu sendiri sebagai submodule untuk generator saya, dan kemudian proyek CMake lainnya (yang dikonfigurasi untuk menghasilkan file build Ninja), dan kemudian membuat file konfigurasi Ninja untuk keduanya dan memasukkannya sebagai subninja s di _my_ project's build.ninja agar dapat membangunnya seolah-olah mereka sendiri, tetapi masih mengizinkan proyek saya untuk menggunakan outputnya (dan dengan demikian grafik ketergantungannya) untuk membangun keseluruhan proyek sekaligus .

Jika itu masuk akal. Kasus penggunaan langsung yang saya lihat dengan generator saya khususnya adalah bahwa ia meminjam beberapa konsep dari Tup (yang IIRC memengaruhi beberapa keputusan desain dalam Ninja itu sendiri) di mana saya dapat menyertakan N subproyek, semuanya dengan build.ninja mereka sendiri file, lalu ketuk grafiknya untuk memungkinkan saya membuat grafik ketergantungan yang jauh lebih besar secara otomatis.

Saya pribadi berpikir itu akan membuat subninja jauh lebih berguna, meskipun saya bisa melihatnya sebagai perubahan yang berpotensi merusak. Namun, saya tidak melihat jalan keluarnya kecuali 1) saya memodifikasi file build.ninja dependensi dengan tambalan atau 2) mengorbankan kemampuan untuk memanfaatkan grafik dependensi dependensi.

Pikiran?

Bagaimana tentang:

subninja path/to/build.ninja relative path/to

dan relative yang tidak ada default ke ./ . Itu akan membuatnya tidak rusak tetapi tetap memberikan fungsionalitas jika generator menginginkannya.

Atau, mengikuti langkah-langkah konstruksi Ninja lainnya, mungkin

subninja path/to/build.ninja
  relative = path/to

Misalkan Anda memiliki proyek di .../foo dan memiliki bilah subdirektori, dan Ninja itu memiliki logika jalur relatif yang Anda sarankan.

Jika sistem build Anda ingin menulis semua output build ke /foo/obj, subninja di /foo/bar yang menggunakan jalur relatif direktori perlu tahu untuk menulis outputnya ke ../obj/bar, karena itulah jalurnya file dari subdirektori itu. Jadi, apa pun yang menghasilkan file build.ninja Anda harus sudah mengetahui hierarki jalur global, dalam hal ini membuat semua jalur relatif secara efektif merupakan masalah yang sama dengan menambahkan bilah/ ke jalur di direktori bar/.

Mungkin ada cukup banyak orang yang menulis output build di direktori sumber mereka sehingga hal di atas tidak masalah. Saya kebanyakan mendengar dari orang-orang yang menginginkan pemisahan yang lebih kuat -- seperti orang-orang yang mengirim patch ke Ninja untuk membuatnya sehingga mereka dapat membangun Ninja dengan output build di direktori yang sama sekali tidak terkait.

Saya tidak yakin saya mengerti. Subninja, dalam kasus penggunaan yang saya jelaskan secara khusus, biasanya tidak tahu tentang struktur ninja induk (setidaknya, tidak perlu tahu). Saya yakin seseorang di luar sana dapat menemukan kasus di mana mereka melakukannya.

Masalah yang saya hadapi saat ini adalah dependensi (perpustakaan pihak ketiga, dll.) yang tidak menggunakan generator saya (yang 100% di antaranya) saat ini perlu dibangun menggunakan bootstrap, dan harus di-bootstrap setiap kali mereka 'diperbarui atau diubah, dll. Sebagian besar generator tempat saya bekerja memiliki opsi untuk menghasilkan konfigurasi ninja, tetapi semuanya dikonfigurasi untuk direktori itu saja (yaitu relatif terhadap direktori itu).

Mampu melakukan rekondisi selektif menggunakan konfigurasi dan grafiknya akan sangat besar. Saat ini, saya tidak dapat melakukan ini karena fakta subninja mengasumsikan jalur relatif terhadap direktori build.

Evan: Cara saya memahami ini adalah bahwa Anda akan membuat pohon seperti ini:

  subbuild1
  subbuild2

dan karena generator biasanya mendukung penempatan direktori build di sembarang tempat, membangun proyek 1 di subbuild1 dan proyek 2 di subbuild 2 akan berfungsi. Lalu ada file ninja tingkat atas di builddir yang Qix- ingin dorong untuk membangun subproyek.

Tidak terkait: fitur relative ini juga harus mengubah cwd ke argumennya jika ada aturan yang bergantung pada direktori saat ini yang sama dengan dir build mereka (misalnya, jika aturan menghapus artefak yang dibuat atau semacamnya).