Lapack: Membangun sistem

Untuk menambahkan ke daftar, build CMake saat ini (tampaknya) mendukung opsi untuk membangun hanya bagian tertentu dari library (NYATA, GANDA, KOMPLEKS dan/atau KOMPLEKS GANDA), sedangkan build Makefile saja tidak. (Saya telah mengubah Makefile dalam salinan yang kami distribusikan dengan OpenBLAS dan dapat menghasilkan PR jika diinginkan - perlu rediff untuk meninggalkan beberapa perubahan yang tidak relevan di sini)

CMake build saat ini (tampaknya) mendukung opsi untuk membangun hanya bagian tertentu dari perpustakaan (NYATA, GANDA, KOMPLEKS dan/atau KOMPLEKS GANDA)

Opsi ini berfungsi terakhir kali saya mencobanya (sekitar Mei 2020).

Build CMake memiliki beberapa opsi, saya mencantumkan yang paling penting bagi saya di sini:

• membangun perpustakaan bersama atau statis
• mengaktifkan atau menonaktifkan tes
• 64- atau 32-bit indeks
• build yang dioptimalkan dan debugging
• pilihan untuk matrix generator library (TMG), penggunaan library BLAS lainnya, BLAS++, LAPACK++...

Ide bagus. Build yang bekerja pada mesin saya dengan make tetapi tidak pada ci dengan CMake telah membuat saya gila beberapa kali.

Secara teknis, saya pikir Makefile juga mendukung banyak opsi tersebut (Anda bisa mengedit make.inc Anda). Jika Anda ingin membangun tanpa tes, Anda dapat membangun dengan make lib . Tapi yang terpenting, membangun perpustakaan bersama tidak didukung. Kebanyakan orang menggunakan LAPACK sebagai perpustakaan bersama sehingga membuat CMake menjadi pemenang yang jelas bagi saya.

Jika kita akhirnya melakukannya, saya sarankan kita menambahkan beberapa instruksi build tambahan ke readme. Cara membangun dan menjalankan tes, cara menambahkan flag, terutama flag frecursive. Mungkin bahkan beberapa catatan kecil tentang cara menggunakan perpustakaan bersama.

Saya menduga akan ada banyak tambalan yang beredar (misalnya di distribusi linux yang mengemas lapack) untuk membangun pustaka bersama dengan gmake. Seharusnya tidak terlalu rumit untuk menambahkan opsi BUILD_SHARED ke make.inc seperti BUILD_DEPRECATED yang sudah ada di sana (dan keduanya cukup tidak jelas di build CMake kecuali ada yang sudah tahu bahwa ccmake dan cmake-gui ada).

Seharusnya tidak terlalu rumit untuk menambahkan opsi BUILD_SHARED ke make.inc seperti BUILD_DEPRECATED yang sudah ada di sana (dan keduanya cukup tidak jelas di build CMake kecuali ada yang sudah tahu bahwa ccmake dan cmake-gui ada).

Tidak perlu bekerja dengan ccmake untuk menyetel salah satu opsi ini. Anda dapat menggunakan baris perintah yang mirip dengan skrip configure dihasilkan oleh autotools:

$ cmake -DBUILD_SHARED_LIBS=ON -DBUILD_COMPLEX=OFF -DBUILD_DEPRECATED=ON -- ../lapack/
[snip]
-- Build deprecated routines: ON
-- Build single precision real: ON
-- Build double precision real: ON
-- Build single precision complex: OFF
-- Build double precision complex: ON
[snip]
$ git -C ~/lapack rev-parse HEAD
6e125a41a7d4905d905a7467d3239d3f0d14b22c

Anda pasti bisa, maksud saya adalah bahwa tidak ada dokumentasi yang jelas kecuali membaca CMakelists.txt (sedangkan README menunjuk satu ke file make.inc yang telah dikonfigurasi sebelumnya untuk gmake). ccmake dan cmake-gui menampilkan daftar opsi yang tersedia, tetapi ini akan hilang pada siapa pun yang baru mengenal cmake.

Jika kita menulis dokumentasi tentang cara menggunakan CMAKE, kita dapat menggunakan saya sebagai pengguna kelinci percobaan karena saya belum pernah menggunakan CMAKE.

Membaca seluruh percakapan, saya merasa bahwa Makefile ada di LAPACK hanya untuk saya. ;)

Aku tidak tahu.

Ya: mempertahankan beberapa sistem pembangunan menyebabkan inkonsistensi. Jadi saya melihat argumen untuk hanya memiliki satu. (Apakah itu CMAKE, make atau meson.) (Oh ya, saya juga tidak pernah menggunakan meson, jika Anda bertanya-tanya.)

Saya khawatir pindah ke CMAKE karena, bukan saja saya tidak tahu cara menggunakannya, saya juga tidak tahu cara merawatnya. Namun sepertinya kami memiliki komunitas yang luar biasa yang dapat membantu, jadi saya tidak dapat mengerjakan bagian proyek ini sepertinya tidak menjadi masalah, selain itu, saya mungkin harus belajar CMAKE.

Semua: Silakan ungkapkan pendapat Anda di utas ini.

Tampaknya sebagian besar dari kita ingin (1) menghapus make dan menghapus meson; (2) pindah ke CMAKE saja; (3) tambahkan beberapa dokumentasi bagus tentang cara menggunakan CMAKE. Baik dengan saya.

Saya akan mengirim beberapa email ke pengelola paket lain di sana-sini untuk menanyakan bagaimana kabar mereka dan apa pendapat mereka tentang masalah ini.

@martin-frbg: bagaimana ini dilakukan di OpenBLAS?

OpenBLAS memiliki Makefiles sebagai sistem build "tradisional" yang "dikenal berfungsi", dan CMAKE sebagai alternatif kontribusi pengguna asli yang masih mengeluarkan peringatan bahwa file yang dihasilkannya mungkin tidak sesuai dengan apa yang akan dilakukan build Makefile.
Saya tidak terlalu menyukai CMAKE, tetapi saya telah belajar membuat file build cmake yang berfungsi (meskipun mungkin terkadang tidak lazim). Menurut pendapat saya, Makefile harus tetap ada (dan saya percaya gmake masih lebih luas daripada cmake). Saya tidak tahu sejarah dukungan meson - _if_ ini adalah kontribusi "dilempar pagar" satu kali yang tidak ada yang tahu atau cukup peduli untuk terus diperbarui, saya kira tidak ada gunanya menyimpannya.

Saya tidak tahu sejarah dukungan meson - jika ini adalah kontribusi "dilempar ke pagar" satu kali yang tidak ada yang tahu atau cukup peduli untuk terus diperbarui, saya kira tidak ada gunanya menyimpannya.

Bangunan Meson diterjunkan ke LAPACK di PR #311.

Hm. Jika diterima ke 3.9.0 (walaupun hanya sebagai bukti konsep), akan terlihat agak aneh untuk membuangnya lagi dengan rilis berikutnya...

Saya menghubungi @therault agar dia bisa memberikan pendapatnya kepada kami, inilah yang dikatakan @therault . Terima kasih @therault!

Open MPI hanya menggunakan autoconf (automake, autoconf, configure, Makefiles).

Untuk PaRSEC dan DPLASMA, kami hanya menggunakan CMake, dan untuk membantu pengguna yang terbiasa mengkonfigurasi, @abouteiller membuat skrip yang menggunakan sintaks configure dan memanggil CMake dengan sintaksnya sendiri.

Saya tahu satu proyek besar yang mencoba mempertahankan konfigurasi dan CMake. Perlahan-lahan berkembang dalam situasi di mana 100% fitur tersedia di CMake, dan semakin sedikit fitur baru yang didukung dalam konfigurasi. Saya percaya bahwa mereka telah berhenti mempertahankan versi konfigurasi.

Mempertahankan dua sistem build untuk sebuah kode itu sulit: secara teori, sistem build harus bekerja dengan kode apa pun, dan dengan demikian mempertahankan dua harus dimungkinkan (dengan biaya tinggi untuk pengelola, untuk menjaganya tetap sinkron, itulah alasan mengapa configure dijatuhkan di proyek lain itu, pengelola memutuskan bahwa dia memiliki hal-hal yang lebih baik untuk dilakukan dengan waktunya). Dalam praktiknya, terkadang perlu untuk mengadaptasi kode ke sistem build untuk membuat segalanya lebih bersih. Ketika itu terjadi, salah satu dari dua sistem pembangunan perlu menggunakan solusi dan peretasan untuk berperilaku seperti yang lain dan sesuai dengan kode.

Pada akhirnya, CMake atau mengkonfigurasi, keduanya akan mengecewakan. Kami adalah programmer / matematikawan / kami melakukan algoritma... Menghabiskan waktu untuk memahami mengapa pada mesin itu, dengan kombinasi kompiler dan flag ini, kode tidak dikompilasi dengan benar, tidak ada yang menyukainya. Lebih buruk lagi, mencoba mencari cara untuk melakukan hal itu atau yang lain menggunakan CMake atau autoconf akan membuat Anda kesulitan :) Bekerja dengan keduanya, saya dapat menjamin Anda akan mengeluh tentang keduanya :) Mempertahankan satu adalah cara yang pasti untuk mengeluh dua kali lebih sedikit.

Hari ini, saya mendukung CMake karena satu alasan: CMake melakukan pekerjaan yang baik dalam menghasilkan file Ninja daripada Makefiles. Ninja mengkompilasi PaRSEC dua kali hingga tiga kali lebih cepat daripada Make -j. Sekarang, mungkin configure/autoconf juga bisa menghasilkan file Ninja, saya belum pernah mencoba... Jika Anda belum pernah mencoba ninja sebelumnya, dan jika LAPACK memiliki versi CMake, saya sarankan Anda mencoba cmake -G Ninja (setelah menginstal Ninja di komputer Anda). Untuk mengkompilasi, Anda memanggil 'ninja' di direktori tempat Anda menjalankan cmake alih-alih 'make'. Anda akan lihat, itu luar biasa :)

Saya senang untuk berkontribusi pada skrip lem configure-to-cmake tersebut ke LAPACK jika itu adalah sesuatu yang Anda minati.
(untuk memperjelas, skrip itu tidak berbasis autoconf/m4, ini adalah skrip sederhana yang mengubah configure --with-feature=value menjadi panggilan ke cmake -DFEATURE=value , dengan sedikit lebih banyak polesan).

LAPACK bahkan tidak menggunakan konfigurasi - dan saya setuju mungkin akan merepotkan untuk menjaga sistem berbasis autoconf/automake/configure bersamaan dengan cmake, dengan autotools itu sendiri terus-menerus "berkembang" dan bergantung pada makro m4 dan yang lainnya.

Saya khawatir pindah ke CMAKE karena, bukan saja saya tidak tahu cara menggunakannya, saya juga tidak tahu cara merawatnya.

Ini adalah alasan utama untuk tetap menggunakan Makefiles.

Semua: Silakan ungkapkan pendapat Anda di utas ini.

Membangun Meson harus dihapus. Tidak ada yang menggunakannya, tidak ada yang tahu bagaimana mempertahankannya, penulis asli mengirimkan build yang tidak lengkap, dan tidak pernah kembali setelah perubahannya digabungkan. Berapa banyak orang yang tahu ada build Meson sebelum saya membuka edisi ini?

CMake adalah sistem build portabel dengan sintaks sederhana dan build yang dapat dikonfigurasi sepenuhnya. Seseorang dapat mengatur opsi spesifik file, spesifik kompiler, atau spesifik target (mis., untuk secara selektif mengaktifkan fungsi yang tidak ada di pustaka standar C seperti gethostname() ). CMake memiliki manajemen file objek yang kuat; ini memungkinkan Anda untuk terus mengetik make untuk memperbarui bangunan Anda bahkan jika Anda mengganti cabang git. CMake berinteraksi dengan baik dengan ekosistem UNIX lainnya: Anda dapat memanggil program arbitrer dan bertindak berdasarkan outputnya. Misalnya, Anda dapat memanggil pkg-config untuk mencari paket lain.

Pertama kali saya menggunakan CMake adalah pada tahun 2016 dan saya telah menggunakannya terus menerus sejak itu untuk membuat kode untuk sistem Linux, Mac, iOS, dan Android, pada arsitektur set instruksi x86, x86-64, armv7, dan aarch64. Ini tersedia di semua distribusi Linux utama dan di semua superkomputer yang saya akses (Grid 5000, Jean Zay, JUWELS, GRICAD, Eagle II). Superkomputer biasanya memiliki beberapa versi yang tersedia termasuk rilis lama dan yang sangat baru (3.18+). Satu-satunya platform di mana saya berjuang dengan ketersediaan CMake adalah CentOS 7 tetapi Anda selalu dapat mengunduh tarball CMake dan menggunakan skrip bootstrap di dalam tarball untuk membangun CMake hanya dengan GNU Make.

CMake hanya bekerja untuk saya.

Pengalaman saya dengan sistem build lain adalah sebagai berikut:

• Bazel: babi memori besar, tidak mungkin dijalankan pada Raspberry Pi dengan memori 1GB, bersikeras untuk membangun semua dependensi, dan menautkan semuanya secara statis
• Autotools: sebagai pengembang tidak memiliki pengalaman, sebagai pengguna skrip configure sangat nyaman karena dapat menunjukkan kepada Anda semua opsi yang tersedia (CMake melakukannya dengan ccmake hanya setelah menjalankan cmake satu kali).

Hari ini, saya mendukung CMake karena satu alasan: CMake melakukan pekerjaan yang baik dalam menghasilkan file Ninja daripada Makefiles. Ninja mengkompilasi PaRSEC dua kali hingga tiga kali lebih cepat daripada Make -j.

Bagus, Ninja tidak bisa mengkompilasi Fortran di masa lalu, lih. ninja #1265 , yaitu, pada beberapa distribusi ini tidak akan berfungsi (Debian 9?).

Saya pasti akan mengatakan makefile biasa lebih mudah dan cukup dalam kasus ini.
Memelihara perangkat lunak di kluster HPC Saya sangat kecewa dengan penggunaan Cmake.

1. Pengembang mengalami kesulitan mengikuti skema penamaan standar yang membuat pembangunan menjadi sulit karena pembacaan dokumentasi yang berlebihan. Setiap paket melakukan beberapa "tweak" nama yang sesuai dengan proyek mereka. Sehingga berakhir di skema penamaan non-standar. (agak benar untuk autoconf+, tapi di sini ada lebih banyak standar)
2. Ketika barang rusak di cmake, itu membutuhkan ahli cmake untuk men-debugnya, saya masih kesulitan men-debug barang... :(
3. Sulit untuk menggunakan file konfigurasi (tidak make.inc ), ini memaksa semua opsi-build untuk ditentukan pada baris perintah pada waktu pembuatan.

Di sisi lain, cmake juga melakukan hal-hal baik:

1. Dukungan windows yang lebih mudah
2. Penanganan dependensi yang lebih otomatis dan penyertaan file cmake untuk proyek lain (ini adalah manfaat yang bagus)

Namun, untuk sistem build LAPACK yang sangat sederhana menurut saya tidak ada yang baik dan buruk. Sistem build saat ini telah bekerja selama beberapa dekade, dan orang-orang sudah terbiasa dengannya.
Juga, untuk pembuatan paralel cepat, ini dapat dengan mudah ditambahkan ke sistem makefile saat ini ...

Saya tidak benar-benar memiliki preferensi, tetapi harus benar -

Saya merasa seperti saya dalam situasi yang sama seperti Anda @langou .

Saya tidak tahu cmake. Saya hanya berhasil menggunakannya untuk proyek ini karena semua konfigurasi sudah ada dan dengan membuka konfigurasi travis dan menyalin dan menempelkan baris yang dijalankannya. Saya tidak berpikir itu hanya karena saya tidak berpengalaman. Makefile sedikit kurang ajaib dan terasa lebih rendah. Itu adalah sesuatu yang mungkin beresonansi dengan tipe orang yang cenderung mengerjakan proyek ini.
Jika murni untuk penggunaan pribadi saya, saya akan tetap menggunakan gmake, tetapi kemudian kami harus memasukkan semua fitur yang saat ini hanya tersedia di cmake ke dalam Makefile. Terutama target perpustakaan bersama.

Namun, saya tidak dapat mengabaikan semua fitur bagus yang sepertinya ditawarkan cmake. Pada akhirnya, saya pikir cmake atau gmake akan baik-baik saja. Kita hanya perlu memilih satu.

Saya orang luar, tetapi sebagai seseorang yang membantu memelihara lapack di conda-forge , memiliki sistem build menjadi CMake akan memiliki beberapa keuntungan (kurang hacky , dukungan windows asli, dll.).

Dibutuhkan beberapa untuk membiasakan diri dengan sintaks CMake, tetapi kesan saya adalah bahwa ini adalah perangkat lunak yang terpelihara dengan baik dan terdokumentasi dengan baik yang telah berhasil memecahkan / mengabstraksikan banyak masalah pembangunan yang degil. Saya juga terlibat dalam pengemasan perpustakaan lain, dan (secara subjektif) melihat semakin banyak perpindahan ke CMake.

Hanya titik data lain dari luar; dalam pekerjaan kami yang melibatkan sedikit pembangunan C/C++, kami pindah ke Meson setelah terlalu banyak berjuang dengan CMake. Daftar panjang masalah dengannya didokumentasikan dengan baik di tempat lain, jadi saya melewatkannya.

Dalam proyek SciPy kami juga akan mencoba menggunakan CMake atau Meson di beberapa titik karena Python distutils sedang dinonaktifkan.

Saya setuju mempertahankan tiga sistem build menyebabkan inkonsistensi dan/atau pekerjaan ekstra untuk pengelola. Namun, berdasarkan komentar di atas dan menurut saya, setiap pengguna memiliki cara sendiri untuk membangun kode. Khususnya, saya setuju dengan komentar @therault :

Kami adalah programmer / matematikawan / kami melakukan algoritma... Menghabiskan waktu untuk memahami mengapa pada mesin itu, dengan kombinasi kompiler dan flag ini, kode tidak dikompilasi dengan benar, tidak ada yang menyukainya. Lebih buruk lagi, mencoba mencari cara untuk melakukan hal itu atau yang lain menggunakan CMake atau autoconf akan membuat Anda kesulitan :) Bekerja dengan keduanya, saya dapat menjamin Anda akan mengeluh tentang keduanya :) Mempertahankan satu adalah cara yang pasti untuk mengeluh dua kali lebih sedikit.

Satu ide untuk menghindari masalah dengan beberapa sistem build adalah:

• Buat lebih banyak konfigurasi di CI sehingga mencakup semua sistem build yang didukung. Dengan cara ini kami menjamin semua sistem build bekerja dengan fitur dasar.
• Presentasikan semua dan sarankan penggunaan salah satu sistem build di README. Mis.: _Kami menyarankan penggunaan CMake jika Anda perlu membangun perpustakaan bersama dan statis, ..._, seperti yang disebutkan oleh @martin-frbg, @christoph-conrads, dan @thijssteel di utas ini. (Saya tidak tahu ada sistem pembangunan Meson di repositori. Saya pikir kita harus menambahkannya di README atau berhenti mempertahankan opsi ini.)

Sejauh yang saya pahami, masalah dengan flag recursive berkaitan dengan rutinitas pengujian xeigtstz (lihat https://github.com/Reference-LAPACK/lapack/issues/335# issuecomment-485021575). Ketika masalah ini diperbaiki, pendapat saya adalah bahwa kami akan memutuskan untuk

1. tambahkan bendera ke konfigurasi CMake default dan di mana pun itu hilang, atau
2. hapus bendera dari file make.inc.* .

Sedikit kesalahpahaman wrt -frecursive Saya pikir - ini diperlukan untuk memfungsikan kode multithread dengan benar, jadi tidak boleh dihapus dari file build secara umum. Namun, efek sampingnya adalah menempatkan array lokal di tumpukan, yang kebetulan sangat besar dalam kasus xeigtstz. Menghapus opsi ini dari (hanya) TESTING/EIG Makefile akan tampak membantu dalam kasus sederhana, tetapi tampaknya tersirat ketika mengkompilasi dengan `-fopenmp' jadi ini bukan solusi umum untuk persyaratan stacklimit yang luar biasa besar dari tes itu.

jadi inilah alasannya.
Saya setuju LAPACK adalah perpustakaan "sederhana" - hanya memiliki sistem make sudah cukup, dan itu sudah cukup untuk waktu yang lama.
Tapi tapi tapi.. ada Windows.. dan hanya karena Windows, kami harus membawa cmake. Awalnya, orang-orang dari CMake mengerjakan konfigurasi, tetapi sekarang saya kira kita sendiri, dan seperti @langou , kita tidak benar-benar menguasainya.
Sekarang sebagian besar perangkat lunak berbasis LAPACK menggunakan Cmake dan kami tahu dari umpan balik pengguna kami, mereka menyukainya.

Jadi jika kita harus memilih satu sistem build: ini harus Cmake... sayangnya untuk saat ini tapi untungnya untuk masa depan.

Suara saya: mengikuti saran @therault dan hanya memiliki satu sistem build, jadi cmake.

Sekarang sebagian besar perangkat lunak berbasis LAPACK menggunakan Cmake dan kami tahu dari umpan balik pengguna kami, mereka menyukainya.

Saya membuka masalah ini dan mengusulkan untuk hanya memiliki satu sistem build. Asumsi saya adalah bahwa keterampilan Makefile dan CMake didistribusikan secara merata. Mohon koreksi jika saya salah tetapi kesan saya adalah bahwa ini tidak benar di antara kontributor LAPACK biasa : Makefile tampaknya populer dan pengetahuan CMake tampaknya tidak kuat. Selain itu, setelah diskusi selama dua hari, flag -frecursive tampaknya merupakan satu-satunya perbedaan antara build CMake dan Makefile dan fakta bahwa hanya CMake yang digunakan di Travis CI. Tidak masuk akal untuk memaksakan satu sistem pembangunan yang membuat pengguna senang jika itu mengusir kontributor inti.

(Penilaian saya tentang siapa yang merupakan kontributor tetap didasarkan pada melihat lima halaman pertama dari pull request yang diterima.)

Setuju.. BTW, flag rekursif berada dalam konfigurasi CMake dan Makefile default dengan #492. Jadi, saya pikir kita hanya perlu menyertakan build Makefile di Travis CI.

PR #500 mengurangi inkonsistensi antara sistem build Makefile dan CMake yang dilaporkan di sini. Lihat https://github.com/Reference-LAPACK/lapack/pull/500#issuecomment -788164244

Hai @ilain. Terima kasih atas informasi Meson / CMake / Makefile. Sangat bagus untuk memiliki umpan balik dari luar, dan mendapatkan informasi tentang apa yang sedang dilakukan proyek lain. Kami tidak dapat mendukung ketiga sistem dan kami lebih memilih CMake dan Makefile untuk saat ini, jadi kami kemungkinan akan menonaktifkan Meson. Bukan berarti kami tidak akan pernah menggunakan Meson, tetapi untuk saat ini, kami tidak memiliki sumber daya untuk memeliharanya. Ini pendapat saya. Saya pikir kami akan mengirimkan PR segera menonaktifkan Meson. Julien.