Чи безпосередньо використання Марк вважається застарілим? [зачинено]

Тому я стикався з багатьма коментарями / публікаціями / тощо, що стосуються створення файлів безпосередньо, і як це нерозумно робити в 2015 році. Я знаю такі інструменти, як CMake, і я фактично використовую CMake досить часто. Вся справа в тому, що CMake просто створює Makefile для вас і допомагає зняти нудьгу, як це зробити самостійно. Звичайно, він додає багато інших чудових функцій ... але це все-таки Makefile врешті-решт.

Отже, моє запитання - це "застаріла" розмова про те, щоб зробити посилання на всю утиліту Make, або просто ідея вручну написати власні Makefiles? Я взагалі не використовую IDE для розробки C / C ++ (лише emacs), тому я завжди писав Makefiles.

Якщо Make вважається застарілим, що C / C ++ розробник повинен використовувати для створення невеликих особистих проектів?

Велика різниця полягає в тому, що CMake є системою мета-побудови між платформ . Один проект CMake може створити звичайний файловий файл Unix / Linux, проект Visual Studio для Windows, проект XCode для Mac та майже будь-яку іншу неметальну систему побудови, яку ви можете використовувати або підтримувати.

Я б не сказав, що використання прямого або навіть вручну редагування файлів "застаріло", але це речі, які ви, мабуть, не повинні робити, якщо ви не працюєте на Unix / Linux, які не потребують перенесення до Windows, як, наприклад, не слід редагувати файли проектів Visual Studio безпосередньо, якщо ви хочете будь-коли перенести їх у не-Windows. Якщо у вас є інтерес до портативності, варто вивчити систему мета-побудови на зразок Scons або CMake.

Невже makeзастаріла?

Я не думаю, що так. Зрештою, make є все ще досить потужним, щоб забезпечити всі необхідні функціональні можливості, як умовна компіляція зміненого джерела тощо. Скажімо, що makeзастаріло, це було б те саме, що говорити про те, що написання спеціальних сценаріїв посилання було застарілим

Але те, makeщо не надає сировини , - це розширені функціональні можливості та фондові бібліотеки для комфорту, такі як генерація параметричних заголовків, інтегрована рамка тестування або навіть просто умовні бібліотеки загалом.

З іншого боку, CMakeвін безпосередньо налаштований на створення загальних бібліотек і виконуваних файлів ELF. Щоразу, коли ви відходите від них заздалегідь визначених процедур, вам потрібно починати злом так CMakeсамо, як ви звикли зламати власні Makefiles.

Зважаючи на те, що ви можете створити набагато більше в C ++, ніж просто середнє додаток для системи, яка знає навантажувачі ELF, CMakeнапевно, не підходить для всіх сценаріїв. Однак якщо ви працюєте в такому стандартизованому середовищі CMakeабо будь-який інший із цих сучасних систем генератора скриптів, безумовно, є вашими найкращими друзями.

Це завжди залежить від того, наскільки спеціалізована ваша програма, і наскільки структура CMakeструктури відповідає вашому робочому потоку.

Колись мови високого рівня були просто ідеєю. Люди намагалися реалізувати компілятори. Тоді були жорсткі обмеження на обладнання - не було графічних інструментів, тому "звичайний текст" в кінцевому підсумку використовувався для формату вхідного файлу; комп'ютери зазвичай мали надзвичайно невелику кількість оперативної пам’яті, тому вихідний код потрібно було розбити на частини, і компілятор розділився на окремі утиліти (попередній процесор, компілятор, асемблер, лінкер); Процесори були повільними і дорогими, тому ви не могли робити дорогих оптимізацій тощо.

Звичайно, якщо багато вихідних файлів і багато утиліт використовуються для створення багатьох об’єктних файлів, безладно будувати що-небудь вручну. У результаті вирішення проблем із дизайном інструментів (спричинених сильно обмеженим обладнанням) люди, природно, почали писати сценарії, щоб усунути деякі проблеми.

На жаль, сценарії були незручними і безладними. Щоб вирішити проблеми зі сценаріями (які були проблемою для недоліків дизайну в інструментах, спричинених обмеженим обладнанням), врешті-решт люди винайшли утиліти, щоб полегшити справи make.

Однак; makefiles незручні та безладні. Щоб вирішити проблеми з makefiles (які були проблемою для вирішення проблем із-за вад дизайну в інструментах, спричинених обмеженим обладнанням), люди почали експериментувати з автоматично створеними makefiles; починаючи з таких речей, як отримання компілятора для генерування залежностей; і переходить до таких інструментів, як автоконфігурація та cmake.

Ось, де ми зараз знаходимося: work-arounds for a work-arounds for a абыймати для недоліків дизайну в інструментах, спричинених обмеженим обладнанням.

Я сподіваюсь, що до кінця століття на вершині наявної купи з’явиться ще кілька шарів "робочої зони для роботи". За іронією долі, суворі обмеження обладнання, що спричинили все це, зникли багато десятиліть тому, і єдина причина, по якій ми все ще використовуємо такий архаїчний безлад, - це так, як це робиться завжди .

make (інструмент або пряме його використання через Makefile) не застаріло, особливо для "невеликих особистих проектів", як ви їх використовуєте.

Звичайно, ви також можете використовувати його для великих проектів, включаючи ті, націлені на кілька платформ. За допомогою змінних, орієнтованих на ціль, ви можете легко налаштувати спосіб створення для різних платформ. На сьогоднішній день дистрибутиви Linux поставляються з ланцюжками інструментів для перекомпіляції (наприклад, mingw-w64 ), тому ви можете скласти повний пакет програмного забезпечення для Windows (з інсталятором, якщо вам подобається) з Linux, який керується вашим Makefile.

Такі інструменти, як cmake та qmake, можуть бути корисними, але вони не позбавлені своїх проблем. Вони, як правило, добре створюють додаток разом із будь-якими бібліотеками (хоча у мене завжди виникали проблеми з qmake, роблячи належну перевірку залежності між бібліотеками та програмами, які ними користуються), але я завжди борюся з обмеженнями цих інструментів, коли роблю іншу частину робота (створення інсталяторів, генерування / встановлення документації чи файлів перекладу, виконання незвичайних речей, таких як перетворення архіву у спільну бібліотеку тощо). Все це можна зробити make, хоча такі речі, як відстеження залежності, можуть зажадати трохи зусиль.

IDE, такі як Qt Creator та Eclipse, також можуть імпортувати проекти на основі Makefile, тому ви можете поділитися з розробниками, що використовують IDE. Я думаю, що Qt Creator IDE чудовий як C ++ IDE, але витративши деякий час на підвищення ефективності роботи з Emacs, і оскільки я займаюся більшою розробкою Ada, я вважаю, що віддаю перевагу Emacs для всього. Щоб повернутися до питання про те make, як крок після посилання в моєму Makefile я оновлюю свій файл TAGS (для навігації по символу в Emacs), завантажений із M-x visit-tags-table:

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

Або для розвитку Ада:

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

Ця відповідь доповнює відповідь @lxrec.

Makefiles можна використовувати для багатьох речей, а не лише для створення програми / бібліотеки з вихідного коду. Системи побудови, такі як CMake або autotools, розроблені для того, щоб приймати код, і будувати його таким чином, щоб вписатися в платформу користувача (тобто знайти бібліотеки або вказати правильні параметри компіляції). Наприклад, ви можете мати файл makefile, який допомагає автоматизувати деякі завдання випуску, такі як: побудувати zip-файл, що містить код з версією, отриманою з git; запустити тести на свій код; завантажте вказаний zip-файл на якусь службу хостингу. Деякі системи побудови (такі як автоматизація) можуть забезпечити простий спосіб зробити це, інші - не.

Це не означає, що для цього вам потрібно використовувати файли, ви можете використовувати мову сценаріїв (оболонку, пітон тощо) для таких завдань.

Я не думаю, що письмові Makefileзаписи людей застаріли, особливо коли:

1. за допомогою POSIX make, яка дає вам портативний Makefile
2. або за допомогою GNU make 4, що дає вам багато дуже цікавих функцій, зокрема сценарій GUILE, який дозволяє ефективно кодувати фантазійні функції, що надаються Makefileгенераторами (я вважаю, що функції автоінструментів або Cmake можна було легко записати за допомогою Guile customisation GNU make ). Звичайно, ціна, яку потрібно платити, - вимагати, щоб GNU склала 4 (не велика справа, ІМХО).

Makefiles не застаріли так само, як текстові файли не застаріли. Збереження всіх даних у простому тексті не завжди є правильним способом вчинити, але якщо все, що вам потрібно, це список списків Todo, то звичайний текстовий файл - це добре. Для чогось більш складного вам може знадобитися складніший формат, як Markdown або XML, або власний бінарний формат або щось середнє, але для простих випадків звичайний текст працює чудово.

Так само, якщо все, що ви хочете, це спосіб уникнути виписки g++ -g src/*.c -o blah -W -Wall -Werror && ./blahвесь час, рукописний Makefile ідеально підходить!

Якщо ви хочете створити щось, що є дуже портативним, де вам не потрібно самостійно керувати цією портативністю, ви, мабуть, хочете, щоб щось на зразок Autotools створило для вас потрібний Makefile. Автоінструменти виявлять функції, підтримувані різними платформами. Програма, написана у стандартному C89, побудованому з Autotools, збиратиметься практично всюди.

якщо ваш проект простий і містить дуже мало файлів, тоді жоден файл створення не потрібен.

Однак, коли проект складний, використовує численні області пам’яті, має багато файлів, то необхідно розмістити кожну область пам’яті в потрібному місці в адресної пам’яті, дуже бажано не перекомпілювати кожен файл кожного разу, коли тривіальна зміна є зроблено в один файл,

Якщо ви хочете стерти старі файли / компілювати / посилати / встановити з мінімальною кількістю клопоту та ймовірності помилок при натисканні клавіш, makefile - справжня користь.

Коли ви потрапляєте в "реальний світ", проекти рідко коли-небудь складають лише 1 або 2 файли, а швидше сотні файлів. makefile завжди буде виконувати правильні дії і не зайві дії (після його налагодження), тому ви вводите лише одну просту команду, і makefile виконує всю роботу