Apakah langsung menggunakan Make dianggap usang? [Tutup]

31

Jadi saya telah menemukan banyak komentar / posting / dll tentang membuat makefile secara langsung, dan bagaimana itu adalah hal yang konyol untuk dilakukan pada tahun 2015. Saya mengetahui alat-alat seperti CMake, dan saya benar-benar menggunakan CMake cukup sering. Masalahnya, CMake hanya menciptakan Makefile untuk Anda dan membantu menghilangkan kebosanan melakukannya sendiri. Tentu saja ia menambahkan banyak fitur hebat lainnya ... tetapi pada akhirnya tetap Makefile.

Jadi pertanyaan saya adalah, apakah pembicaraan 'usang' tentang make merujuk ke keseluruhan utilitas Utilitas, atau hanya gagasan menulis secara manual Makefiles Anda sendiri? Saya tidak menggunakan IDE untuk pengembangan C / C ++ sama sekali (hanya emacs), jadi saya selalu menulis Makefiles.

Jika Make dianggap ketinggalan jaman, apa yang seharusnya digunakan oleh seorang pengembang C / C ++ untuk membangun proyek pribadi yang kecil?

— JParrilla
sumber

8

Untuk proyek-proyek kecil, pribadi a maketanpa Makefile sudah cukup. Apa masalahnya?

— ott--

8

Setiap bagian dari perangkat lunak yang tersedia di sistem FreeBSD saya, baik desktop dan server, memiliki Makefile yang dimulai oleh 'make'. Tidak. 'Make' tidak usang.

— Rob

3

Orang bebas menggunakan IDE, tetapi jika IDE mereka tidak dapat mendukung proyek yang menggunakan Makefiles hampir 40 tahun setelah makepertama kali ditulis, maka mereka seharusnya tidak mengharapkan orang untuk mengatasinya.

— Rute Mil

1

The "usang bicara tentang make" hanya merupakan gejala atau titik rasa sakit , bukan proklamasi bantahan. Terutama ketika penggantian total yang unggul belum ada, dan semua pendekatan untuk mengurangi rasa sakit masih menggunakan membuat dalam beberapa hal, hanya tersembunyi dari pengguna yang paling rentan terhadap rasa sakit. Meskipun banyak jawaban baik telah diberikan, pertanyaan itu sendiri didasarkan pada opini batas.

— rwong

1

CMakeadalah lapisan abstraksi. Ini abstraksi diperlukan untuk menjinakkan berbagai liar konsumen IDE-produk yang tidak akan mematuhi open-source Makefile. Sekali lagi ini bukan hanya abstraksi, tetapi memungkinkan konfigurasi (seperti autoconf). Seperti abstraksi lain, ini memungkinkan alternatif . Tapi itu membuka jalan ide eksperimental baru alternatif Makefile mudah tersedia bagi para pengguna CMake.

— shuva

30

Perbedaan besar adalah bahwa CMake adalah sistem meta-build lintas-platform . Proyek CMake tunggal dapat menghasilkan makefile Unix / Linux, proyek Visual Studio untuk Windows, proyek XCode untuk Mac, dan hampir semua sistem build non-meta lain yang mungkin ingin Anda gunakan atau dukung.

Saya tidak akan mengatakan menggunakan make secara langsung atau bahkan mengedit makefile secara manual adalah "usang", tetapi itu adalah hal-hal yang mungkin tidak boleh Anda lakukan kecuali jika Anda mengerjakan hal-hal Unix / Linux yang tidak perlu porting ke Windows, seperti bagaimana Anda tidak boleh mengedit file proyek Visual Studio secara langsung jika Anda pernah ingin port-nya ke bukan-Windows. Jika Anda tertarik pada portabilitas, ada baiknya mempelajari sistem meta-build seperti Scons atau CMake.

— Ixrec
sumber

9

POSIX makejuga lintas platform.

— Blrfl

6

@Blrfl ini mungkin benar, tetapi umumnya Anda akan menemukan baris perintah yang perlu Anda gunakan untuk mengkompilasi dan / atau menautkan proyek Anda adalah platform spesifik, bahkan jika semua platform yang Anda targetkan sesuai dengan POSIX dan bahkan jika Anda Sedang menggunakan kompiler yang sama pada semua (masih akan ada masalah sial dengan lokasi file sertakan, apakah Anda perlu -lm, -lnsldan sebagainya atau apakah fasilitas tersebut termasuk dalam perpustakaan C, dll).

— Jules

5

@ Jules Ada lebih banyak (atau kurang) untuk CMake, pada dasarnya dirancang untuk pembuatan aplikasi modular dan standar Anda untuk sistem dengan ELF loader, dan menyediakan abstraksi untuk semua alat yang diperlukan untuk rantai alat tertentu. Jika Anda keluar dari toolchain itu (mis. Skrip linker kustom untuk bare metal), CMaketiba-tiba tidak memberikan dukungan atau portabilitas sama sekali, Anda akhirnya meretasnya sama seperti Anda biasa meretas skrip pembuatan kustom sepenuhnya.

— Ext3h

Hal yang sama berlaku untuk Q make (meskipun tidak berperilaku buruk yang tidak konsisten dengan ** ap CMake), btw;)

— mlvljr

11

Apakah makebenar-benar ketinggalan jaman?

Saya kira tidak. Pada akhirnya, make masih cukup kuat untuk menyediakan semua fungsionalitas yang diinginkan, seperti kompilasi bersyarat dari sumber yang diubah dan sama. Mengatakan makesudah ketinggalan zaman, akan sama dengan mengatakan menulis skrip tautan kustom sudah usang.

Tetapi yang mentah maketidak menyediakan, adalah fungsionalitas yang diperluas dan pustaka stok untuk kenyamanan, seperti pembuatan header parametrik, kerangka kerja pengujian terintegrasi, atau bahkan hanya pustaka bersyarat pada umumnya.

Di sisi lain, CMakesecara langsung dirancang untuk menghasilkan pustaka dan executable ELF generik. Setiap kali Anda meninggalkan prosedur yang telah ditentukan, Anda harus mulai meretas CMakeseperti halnya Anda meretas Makefile Anda sendiri.

Menimbang bahwa Anda dapat membuat lebih banyak dalam C ++ daripada hanya aplikasi rata-rata Anda untuk sistem yang tahu loader ELF, CMaketentu tidak cocok untuk semua skenario. Namun, jika Anda bekerja di lingkungan yang terstandar seperti itu, CMakeatau yang lain dari kerangka pembuat skrip modern ini tentu saja adalah teman terbaik Anda.

Itu selalu tergantung pada seberapa khusus aplikasi Anda, dan seberapa baik struktur CMakekerangka kerja sesuai dengan alur kerja Anda.

— Ext3h
sumber

Meskipun berguna, make adalah sistem yang mengerikan dengan braindead, sintaksis misterius, dan banyak batasan yang tidak perlu yang membuat banyak momen-oops.

— antred

7

Sekali waktu bahasa tingkat tinggi hanya sebuah ide. Orang-orang mencoba menerapkan kompiler. Saat itu ada keterbatasan perangkat keras yang parah - tidak ada alat grafis sehingga "teks biasa" akhirnya digunakan untuk format file input; komputer biasanya memiliki jumlah RAM yang sangat kecil sehingga kode sumber harus dipecah menjadi beberapa bagian dan kompiler dapat dipecah menjadi utilitas yang terpisah (pra-prosesor, kompiler, assembler, tautan); CPU lambat dan mahal sehingga Anda tidak bisa melakukan optimisasi mahal, dll.

Tentu saja dengan banyak file sumber dan banyak utilitas yang digunakan untuk membuat banyak file objek, sangat berantakan untuk membuat apa pun secara manual. Sebagai solusi untuk kelemahan desain pada alat (yang disebabkan oleh perangkat keras yang sangat terbatas) orang secara alami mulai menulis skrip untuk menghapus beberapa kerumitan.

Sayangnya, skripnya canggung dan berantakan. Untuk mengatasi masalah dengan skrip (yang merupakan solusi untuk kekurangan desain pada alat yang disebabkan oleh perangkat keras yang terbatas) akhirnya orang menemukan utilitas untuk mempermudah, seperti make.

Namun; makefiles canggung dan berantakan. Untuk mengatasi masalah makefile (yang merupakan solusi untuk work-around untuk cacat desain pada alat yang disebabkan oleh perangkat keras yang terbatas) orang-orang mulai bereksperimen dengan makefile yang dibuat secara otomatis; dimulai dengan hal-hal seperti mendapatkan kompiler untuk menghasilkan dependensi; dan mengarah ke alat-alat seperti auto-conf dan cmake.

Di sinilah kita sekarang: bekerja di sekitar untuk bekerja di sekitar untuk bekerja di sekitar untuk kekurangan desain pada alat yang disebabkan oleh perangkat keras yang terbatas.

Ini adalah harapan saya bahwa pada akhir abad ini akan ada beberapa lapisan "work-arounds for work-arounds" di atas tumpukan yang ada. Ironisnya, keterbatasan perangkat keras yang parah yang menyebabkan semua ini lenyap beberapa dekade yang lalu dan satu-satunya alasan kita masih menggunakan kekacauan kuno sekarang adalah " ini adalah bagaimana itu selalu dilakukan ".

— Brendan
sumber

1

Jadi apa alternatifnya? Apakah alternatifnya benar-benar mengubah konsep bangunan seperti yang kita ketahui?

— JParrilla

1

@Darkslash: Setelah Anda mulai mempertimbangkan alternatif (hipotetis) itu seperti membuka pintu air - Anda berakhir mempertanyakan segalanya (dan berakhir dengan ide-ide seperti pemisahan semantik dan sintaksis, dan mendesain ulang IDE dan alat dan pengiriman sebagai satu set daripada masing-masing bagian dari puzzle yang lebih besar). Lebih praktis adalah menyadari bahwa alat seperti cmakehanya mengobati gejala dan tidak dapat menyembuhkan akar penyebabnya; yang membuatnya lebih mudah untuk menerima kenyataan bahwa Anda tidak punya pilihan selain menggunakan alat yang mungkin tidak akan pernah mendekati "ideal".

— Brendan

5

Makefiles sama sekali tidak 'canggung dan berantakan'. Mereka sangat elegan: makepada intinya merupakan mesin untuk melintasi grafik ketergantungan asiklik. Tidak ada tentang 'skrip' atau baris perintah yang 'kuno'.

— Miles Rout

1

@MilesRout: Bagian yang canggung dan berantakan adalah konstruksi grafik. Traversalnya cukup elegan. Tapi ambil saja contoh paling umum dari bagian berantakan: file header C. Masing #include- masing adalah tepi, tetapi maketidak dapat mengurai file C. Masih tidak masalah, karena makebisa menyimpan tepi ini dengan simpul berikutnya (file * .o), tetapi tidak juga melakukannya.

— MSalters

3

Saya tidak setuju bahwa desain yang lebih baik adalah mungkin. makebukan hanya untuk mengkompilasi C! Anda ingin program yang mengambil .cdan .hfile dan memberi Makefile. Tapi itu tidak make, dan bukan itu yang makeharus dilakukan. Sekali lagi, maketidak semua tentang C, dan solusi spesifik C yang dibangun ke dalamnya makeadalah ide yang buruk (dan kebetulan merupakan pelanggaran terhadap filosofi UNIX).

— Miles Rout

5

make (alat atau penggunaan langsung melalui Makefile) tidak ketinggalan zaman, terutama untuk "proyek pribadi kecil" seperti yang Anda gunakan.

Tentu saja, Anda juga dapat menggunakannya untuk proyek yang lebih besar, termasuk yang ditargetkan untuk beberapa platform. Dengan variabel spesifik target, Anda dapat dengan mudah menyesuaikan cara membangun untuk berbagai platform. Saat ini, distribusi Linux dilengkapi dengan cross-compiling toolchains (mis. Mingw-w64 ) sehingga Anda dapat membangun paket perangkat lunak Windows lengkap (dengan installer jika Anda suka) dari Linux, semuanya didorong dari Makefile Anda.

Alat seperti cmake dan qmake bisa berguna, tetapi mereka bukan tanpa masalah. Mereka biasanya baik untuk membangun aplikasi itu sendiri bersama dengan perpustakaan apa pun (meskipun saya selalu memiliki masalah dengan qmake melakukan pemeriksaan dependensi yang tepat antara perpustakaan dan program yang menggunakannya), tapi saya selalu berjuang dengan kendala alat-alat itu ketika melakukan sisa pekerjaan (membuat installer, membuat / menginstal dokumentasi atau file terjemahan, melakukan hal-hal yang tidak biasa seperti mengubah arsip menjadi perpustakaan bersama, dll.). Semua ini dapat dilakukan make, meskipun hal-hal seperti pelacakan ketergantungan mungkin memerlukan sedikit usaha.

IDE seperti Qt Creator dan Eclipse juga dapat mengimpor proyek berbasis Makefile, sehingga Anda dapat berbagi dengan pengembang yang menggunakan IDE. Saya pikir Qt Creator IDE sangat bagus sebagai C ++ IDE, tetapi setelah menghabiskan waktu untuk menjadi lebih efektif dengan Emacs, dan karena saya melakukan lebih banyak pengembangan Ada, saya mendapati diri saya lebih memilih Emacs untuk semuanya. Untuk menghubungkan kembali ke pertanyaan tentang make, sebagai langkah pasca-tautan di Makefile saya, saya memperbarui file TAGS saya (untuk navigasi simbol di Emacs), yang dimuat dengan M-x visit-tags-table:

find $(SRC_DIR) $(TEST_DIR) -regex ".*\.[ch]\(pp\)?" -print | etags -

Atau untuk pengembangan Ada:

find $(SRC_DIR) $(TEST_DIR) -name "*.ad?" -print | etags -

— Patrick
sumber

2

Jawaban ini melengkapi jawaban @ lxrec.

Makefile dapat digunakan untuk banyak hal, tidak hanya membuat program / perpustakaan dari kode sumber. Membangun sistem seperti CMake atau autotools dirancang untuk mengambil kode, dan membangunnya sedemikian rupa agar sesuai dengan platform pengguna (yaitu menemukan perpustakaan atau menentukan opsi kompilasi yang benar). Misalnya Anda dapat memiliki makefile yang membantu mengotomatiskan beberapa tugas rilis, seperti: membuat file zip yang berisi kode dengan versi yang berasal dari git; jalankan tes terhadap kode Anda; unggah file zip tersebut ke beberapa layanan hosting. Beberapa sistem build (seperti automake) mungkin menyediakan cara mudah untuk melakukan ini, yang lain mungkin tidak.

Itu tidak berarti Anda perlu menggunakan makefile untuk ini, Anda bisa menggunakan bahasa scripting (shell, python dll) untuk tugas-tugas seperti itu.

— James Tocknell
sumber

1

Saya tidak berpikir bahwa tulisan manusia Makefilesudah usang, terutama ketika:

menggunakan POSIX make, yang memberi Anda portable Makefile
atau menggunakan GNU make 4, yang memberi Anda banyak fitur yang sangat menarik, khususnya skrip GUILE, yang memungkinkan untuk kode efisien fitur mewah yang disediakan oleh Makefilegenerator (saya percaya bahwa fitur autotools atau Cmake dapat dengan mudah ditulis oleh kustomisasi Guile membuat GNU make ). Tentu saja, harga yang harus dibayar adalah untuk meminta GNU make 4 (bukan masalah besar, IMHO).

— Basile Starynkevitch
sumber

0

Makefile tidak usang, dengan cara yang sama bahwa file teks tidak usang. Menyimpan semua data dalam teks biasa tidak selalu merupakan cara yang tepat untuk melakukan sesuatu, tetapi jika semua yang Anda inginkan adalah Daftar Todo maka file teks biasa baik-baik saja. Untuk sesuatu yang lebih rumit, Anda mungkin menginginkan format yang lebih rumit seperti Markdown atau XML atau format biner khusus atau apa pun di antaranya, tetapi untuk kasus sederhana teks biasa berfungsi dengan baik.

Demikian pula, jika semua yang Anda inginkan adalah cara untuk tidak menulis g++ -g src/*.c -o blah -W -Wall -Werror && ./blahsepanjang waktu, Makefile yang ditulis tangan sempurna!

Jika Anda ingin membangun sesuatu yang sangat portabel, di mana Anda tidak harus mengelola portabilitas itu sendiri, Anda mungkin ingin sesuatu seperti Autotools untuk menghasilkan Makefile yang tepat untuk Anda. Autotools akan mendeteksi fitur yang didukung oleh berbagai platform. Sebuah program yang ditulis dalam standar C89 yang dibangun dengan Autotools akan mengkompilasi hampir di mana-mana.

— Miles Rout
sumber

"akan dikompilasi secara virtual di mana-mana" -> "akan dikompilasi pada sistem mirip Unix terbaru". Saya tidak berpikir autotoolsbekerja pada tingkat yang relevan pada sistem Windows, misalnya (diskon Cygwin / MingW, yang benar-benar sistem mirip Unix di atas Windows).

— sleske

Ini tidak ada hubungannya dengan menjadi baru. Keuntungan autotools adalah ia bekerja pada setiap sistem mirip POSIX dari jarak jauh. Windows agak kompatibel dengan POSIX.

— Miles Rout

Ya, saya berdiri dikoreksi. Sebenarnya, saya ingat salah satu kritik terhadap autotool adalah justru mengandung kode bahkan untuk sistem yang sangat lama, jadi goreskan "baru-baru ini". Saya masih mendukung bagian Windows.

— sleske

Dan kesalahan untuk itu sepenuhnya terletak pada Microsoft. Jika mereka peduli untuk menghasilkan produk yang berkualitas maka Windows akan memiliki dukungan yang tepat untuk standar sistem operasi internasional (seperti POSIX). POSIX bukan hanya "Unix hal", itu yang standar sistem operasi portabel untuk semua sistem operasi. Windows hanyalah tumpukan sampah yang tidak patuh.

— Miles Rout

@MilesRout masih intinya adalah bahwa "hampir di mana-mana" tidak termasuk komputer desktop 90% .

— el.pescado

-2

jika proyek Anda sederhana dan berisi sangat sedikit file, maka tidak perlu membuat file.

Namun, ketika proyek ini kompleks, menggunakan banyak area memori, memiliki banyak file, maka perlu untuk menempatkan setiap area memori di tempat yang tepat dalam memori yang dapat dialamatkan, sangat diinginkan untuk tidak mengkompilasi ulang setiap file setiap kali perubahan sepele adalah dibuat untuk satu file,

Jika Anda ingin menghapus file lama / kompilasi / tautan / instal dengan jumlah minimum kerumitan dan kemungkinan kesalahan penekanan tombol, makefile adalah anugerah nyata.

Ketika Anda masuk ke proyek 'dunia nyata' jarang hanya ada 1 atau 2 file, tetapi ratusan file. makefile akan selalu melakukan tindakan yang benar dan tidak ada tindakan yang tidak perlu (setelah di-debug) sehingga Anda hanya mengetik satu perintah sederhana dan makefile melakukan semua pekerjaan

— pengguna3629249
sumber

1

Itu tidak menjawab mengapa memilih makelebih dari cmakeatau sebaliknya.

— Ext3h

Menggunakan makefiles tidak membangun kembali semua file setiap saat. (kalau tidak, CMake atau Auto-tools tidak dapat menggunakannya)

— ideasman42