Czy bezpośrednie korzystanie z Make Make jest przestarzałe? [Zamknięte]

31

Natknąłem się więc na wiele komentarzy / postów itp. Dotyczących bezpośredniego tworzenia plików makefile i tego, jak głupio jest to robić w 2015 roku. Zdaję sobie sprawę z narzędzi takich jak CMake, i faktycznie używam CMake dość często. Chodzi o to, że CMake po prostu tworzy plik Makefile dla Ciebie i pomaga usunąć nudę robienia tego samemu. Oczywiście dodaje wiele innych wspaniałych funkcji ... ale w końcu jest to wciąż Makefile.

Moje pytanie brzmi: czy „przestarzała” rozmowa dotycząca make odnosi się do całego narzędzia Make, czy po prostu pomysł ręcznego pisania własnych plików Makefiles? W ogóle nie używam IDE do programowania w C / C ++ (tylko emacs), więc zawsze pisałem Makefile.

Jeśli Make jest uważany za przestarzały, to czego powinien używać programista C / C ++ do tworzenia małych, osobistych projektów?

JParrilla
źródło
8
W przypadku małych, osobistych projektów makewystarczy plik Makefile. Co za kłopot
ott--
8
Każde dostępne oprogramowanie w moich systemach FreeBSD, zarówno na komputery stacjonarne, jak i serwery, ma plik Makefile uruchamiany przez „make”. Nie. „Make” nie jest przestarzałe.
Rob
3
Ludzie mogą swobodnie korzystać z IDE, ale jeśli ich IDE nie mogą obsługiwać projektów korzystających z Makefiles prawie 40 lat po tym, jak makezostał napisany po raz pierwszy, to nie powinni oczekiwać, że ludzie to obejdą.
Miles Rout
1
„Przestarzałe Dyskusja dotycząca make” jest po prostu objawem lub punkt ból , a nie głoszenie amortyzację. Zwłaszcza, gdy jeszcze nie istnieje lepsza całkowita wymiana, a wszystkie podejścia do zmniejszania bólu nadal są stosowane w pewien sposób, po prostu ukryte przed użytkownikami, którzy są najbardziej podatni na ból. Chociaż udzielono wielu dobrych odpowiedzi, samo pytanie jest graniczne na podstawie opinii.
rwong 16.04.15
1
CMakejest warstwą abstrakcji. Ta abstrakcja jest potrzebna, aby oswoić dziką różnorodność konsumenckich produktów IDE, które nie będą zgodne z otwartym oprogramowaniem Makefile. Znowu jest to nie tylko abstrakcja, ale także pozwala na konfigurację (np. Autoconf). Podobnie jak inne abstrakcje, pozwala na alternatywy . Ale toruje drogę eksperymentalnej nowej idei alternatyw Makefile łatwo dostępnych dla użytkowników CMake.
shuva

Odpowiedzi:

30

Dużą różnicą jest to, że CMake to wieloplatformowy system meta-kompilacji. Pojedynczy projekt CMake może wygenerować zwykły plik maksu Unix / Linux, projekt Visual Studio dla Windows, projekt XCode dla komputerów Mac i prawie każdy inny system kompilacji niemeta, którego możesz chcieć używać lub obsługiwać.

Nie powiedziałbym, że używanie make bezpośrednio lub nawet ręczna edycja plików makefile jest „przestarzała”, ale są to rzeczy, których prawdopodobnie nie powinieneś robić, chyba że pracujesz na systemach Unix / Linux, które nie będą wymagały przenoszenia do systemu Windows, podobnie jak nie powinno się bezpośrednio edytować plików projektu Visual Studio, jeśli kiedykolwiek chcesz je przenieść do systemu innego niż Windows. Jeśli interesujesz się przenośnością, warto nauczyć się systemu meta-kompilacji, takiego jak Scons lub CMake.

Ixrec
źródło
9
POSIX makejest także wieloplatformowy.
Blrfl 10.04.15
6
@Blrfl może to być prawda, ale generalnie znajdziesz wiersze poleceń, których potrzebujesz, aby skompilować i / lub połączyć swój projekt, specyficzne dla platformy, nawet jeśli wszystkie platformy, na które celujesz, są zgodne z POSIX, a nawet jeśli używam tego samego kompilatora na wszystkich (nadal będą nieznośne problemy z lokalizacjami plików dołączeń, czy potrzebujesz -lm, -lnslitd. lub czy te funkcje są zawarte w bibliotece C itp.).
Jules
5
@Jules Jest o wiele więcej (lub mniej) CMake, jest on zasadniczo dostosowany do stworzenia standardowej, modułowej aplikacji dla systemów z modułami ładującymi ELF i zapewnia abstrakcje dla wszystkich narzędzi wymaganych dla tego konkretnego łańcucha narzędzi. Jeśli odejdziesz od tego zestawu narzędzi (np. Niestandardowego skryptu linkera dla gołego metalu), CMakenagle nie zapewnia on żadnej obsługi ani przenośności, w końcu hakujesz go tak samo, jak hakowałeś w pełni niestandardowe skrypty budowania.
Ext3h
To samo dotyczy Q make (mimo że nie jest źle udokumentowanym niekonsekwentnym zachowaniem ** ap CMake is), btw;)
mlvljr 13.04.15
11

Czy makenaprawdę jest przestarzały?

Nie wydaje mi się Ostatecznie make jest wciąż wystarczająco wydajny, aby zapewnić wszystkie pożądane funkcje, takie jak kompilacja warunkowa zmienionego źródła i podobne. Mówienie makebyło nieaktualne, byłoby to tak samo, jak pisanie niestandardowych skryptów linkera było przestarzałe.

Ale tym, czego makenie zapewnia Raw , są rozszerzone funkcjonalności i biblioteki podstawowe dla wygody, takie jak parametryczne generowanie nagłówka, zintegrowane środowisko testowe, a nawet po prostu biblioteki warunkowe w ogóle.

Z drugiej strony CMakejest bezpośrednio dostosowany do generowania ogólnych bibliotek ELF i plików wykonywalnych. Ilekroć odejdziesz od wstępnie zdefiniowanych procedur, musisz zacząć hakować CMaketak samo, jak zwykłeś hakować własne pliki Makefile.

Biorąc pod uwagę, że możesz stworzyć znacznie więcej w C ++ niż tylko przeciętna aplikacja dla systemu znającego moduły ładujące ELF, z CMakepewnością nie nadaje się do wszystkich scenariuszy. Jednak jeśli pracujesz w tak znormalizowanym środowisku CMakelub w którymkolwiek z tych nowoczesnych frameworków generujących skrypty, z pewnością są twoimi najlepszymi przyjaciółmi.

Zawsze zależy od tego, jak wyspecjalizowana jest Twoja aplikacja i od tego, jak dobrze struktura CMakeframeworka pasuje do Twojego przepływu pracy.

Ext3h
źródło
Chociaż użyteczne, make jest okropnym systemem z braindead, tajemną składnią i mnóstwem niepotrzebnych ograniczeń, które sprawiają, że wiele chwil nie działa.
antred
7

Dawno temu języki wysokiego poziomu były tylko pomysłem. Ludzie próbowali wdrożyć kompilatory. W tamtym czasie istniały poważne ograniczenia sprzętowe - nie było żadnych narzędzi graficznych, więc do formatu pliku wejściowego użyto „zwykłego tekstu”; komputery zazwyczaj miały bardzo małą ilość pamięci RAM, więc kod źródłowy musiał zostać podzielony na części, a kompilator został podzielony na osobne narzędzia (preprocesor, kompilator, asembler, linker); Procesory były powolne i drogie, więc nie można było dokonywać kosztownych optymalizacji itp.

Oczywiście przy wielu plikach źródłowych i wielu narzędziach używanych do tworzenia wielu plików obiektowych, budowanie czegokolwiek ręcznie jest niepotrzebne. W celu obejścia wad projektowych (spowodowanych przez poważnie ograniczony sprzęt) ludzie naturalnie zaczęli pisać skrypty, aby usunąć część problemów.

Niestety skrypty były niewygodne i nieporządne. Aby obejść problemy ze skryptami (które były obejściem wad projektowych w narzędziach spowodowanych ograniczonym sprzętem), w końcu ludzie wymyślili narzędzia ułatwiające, takie jak make.

Jednak; makefile są niewygodne i nieporządne. Aby obejść problemy z plikami makefile (które były obejściem obejścia błędów projektowych w narzędziach spowodowanych ograniczonym sprzętem) ludzie zaczęli eksperymentować z automatycznie generowanymi plikami makefile; zaczynając od rzeczy takich jak zmuszenie kompilatora do generowania zależności; i prowadząc do narzędzi takich jak auto-conf i cmake.

Oto gdzie jesteśmy teraz: obejścia obejścia obejścia problemu w celu obejścia wad projektowych w narzędziach spowodowanych ograniczonym sprzętem.

Oczekuję, że do końca wieku pojawi się jeszcze kilka warstw „obejść obejścia” na istniejącym stosie. Jak na ironię, poważne ograniczenia sprzętowe, które spowodowały to wszystko, zniknęły wiele dziesięcioleci temu, a jedynym powodem, dla którego wciąż używamy tak archaicznego bałaganu, jest „ tak zawsze było ”.

Brendan
źródło
1
Więc jaka jest alternatywa? Czy alternatywa całkowicie zmienia koncepcję kompilacji, jaką znamy?
JParrilla
1
@Darkslash: Kiedy zaczniesz rozważać (hipotetyczne) alternatywy, to jak otwieranie zastawek - w końcu kwestionujesz wszystko (i kończysz na pomysłach takich jak rozdzielenie semantyki i składni oraz przeprojektowanie IDE i narzędzi oraz dostarczania jako zestawu, a nie poszczególnych elementów większe puzzle). Bardziej praktyczne jest uświadomienie sobie, że narzędzia takie jak cmaketylko leczą objawy i nie mogą wyleczyć pierwotnej przyczyny; co ułatwia zaakceptowanie faktu, że nie masz innego wyboru niż użycie narzędzi, które prawdopodobnie nigdy nie będą zbliżone do „ideału”.
Brendan
5
Pliki makefile nie są w żaden sposób „niewygodne i nieuporządkowane”. Są niewiarygodnie eleganckie: makesą w istocie silnikiem przemierzającym acykliczny wykres zależności. Nic o „skryptach” ani wierszu poleceń nie jest „archaiczne”.
Miles Rout
1
@MilesRout: Niezręczna i niechlujna część to konstrukcja wykresu. Przejście jest wystarczająco eleganckie. Ale weźmy tylko jeden najczęstszy przykład niechlujnej części: pliki nagłówkowe C. Każda z nich #includejest krawędzią, ale makenie może analizować plików C. Nadal nie stanowi to problemu, ponieważ makemoże przechowywać te krawędzie w następnym węźle (plik * .o), ale też tego nie robi.
MSalters
3
Nie zgadzam się, że możliwy jest lepszy projekt. makesłuży nie tylko do kompilacji C! Chcesz program, który pobiera .ci .harchiwizuje i daje Makefiles. Ale tak nie jest makei nie makepowinno tak być. Ponownie, makenie chodzi tylko o C, a wbudowane rozwiązanie specyficzne dla C makejest złym pomysłem (i nawiasem mówiąc, stanowi naruszenie filozofii UNIX).
Miles Rout
5

make (narzędzie lub bezpośrednie korzystanie z niego za pomocą pliku Makefile) nie jest przestarzałe, szczególnie w przypadku „małych, osobistych projektów”, gdy go używasz.

Oczywiście można go również używać do większych projektów, w tym do wielu platform. Dzięki zmiennym specyficznym dla celu możesz łatwo dostosować sposób budowania dla różnych platform. Obecnie dystrybucje Linuksa są dostarczane z kompilującymi się zestawami narzędzi (np. Mingw-w64 ), dzięki czemu możesz zbudować kompletny pakiet oprogramowania Windows (z instalatorem, jeśli chcesz) z Linuksa, wszystkie sterowane z Twojego Makefile.

Narzędzia takie jak cmake i qmake mogą być przydatne, ale nie są bezproblemowe. Zwykle nadają się do budowania aplikacji wraz z dowolnymi bibliotekami (chociaż zawsze miałem problemy z qmake wykonującym prawidłowe sprawdzanie zależności między bibliotekami i programami, które ich używają), ale zawsze walczę z ograniczeniami tych narzędzi, wykonując resztę zadanie (tworzenie instalatorów, generowanie / instalowanie dokumentacji lub tłumaczeń, wykonywanie nietypowych czynności, takich jak przekształcanie archiwum w bibliotekę współdzieloną itp.). Wszystko to można zrobić make, chociaż takie rzeczy jak śledzenie zależności mogą wymagać trochę wysiłku.

IDE, takie jak Qt Creator i Eclipse, mogą również importować projekty oparte na Makefile, dzięki czemu można je udostępniać programistom używającym IDE. Myślę, że Qt Creator IDE jest doskonały jako IDE C ++, ale po spędzeniu czasu, aby stać się bardziej efektywnym z Emacsem, a ponieważ robię więcej rozwoju Ada, wolę Emacsa do wszystkiego. Aby odnieść się do pytania o make, jako krok po linku w moim Makefile, aktualizuję mój plik TAGS (do nawigacji symboli w Emacsie), załadowany M-x visit-tags-table:

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

Lub dla rozwoju Ady:

find $(SRC_DIR) $(TEST_DIR) -name "*.ad?" -print | etags -
Patrick
źródło
2

Ta odpowiedź uzupełnia odpowiedź @lxrec.

Makefile mogą być używane do wielu rzeczy, nie tylko do tworzenia programu / biblioteki z kodu źródłowego. Systemy kompilacji, takie jak CMake lub autotools, są zaprojektowane do pobierania kodu i budowania go w taki sposób, aby pasował do platformy użytkownika (tj. Znajdował biblioteki lub określał prawidłowe opcje kompilacji). Możesz na przykład mieć plik makefile, który pomaga zautomatyzować niektóre zadania wydania, takie jak: zbuduj plik zip zawierający kod z wersją pochodzącą z git; uruchom testy na swoim kodzie; prześlij wspomniany plik zip do jakiejś usługi hostingowej. Niektóre systemy kompilacji (takie jak automake) mogą być łatwym sposobem, inne mogą tego nie robić.

Nie oznacza to, że musisz do tego używać plików makefile, do takich zadań możesz użyć języka skryptowego (powłoki, pytona itp.).

James Tocknell
źródło
1

Nie sądzę, że ludzkie teksty Makefilesą przestarzałe, zwłaszcza gdy:

  1. za pomocą marki POSIX, która daje przenośny Makefile
  2. lub za pomocą GNU make 4, który daje wiele bardzo interesujących funkcji, w szczególności skryptowalność GUILE, która umożliwia efektywne kodowanie fantazyjnych funkcji dostarczanych przez Makefilegeneratory (wierzę, że funkcje autotools lub Cmake można łatwo napisać dzięki dostosowaniu GNU make make ). Oczywiście, cena do zapłaty to wymagać GNU make 4 (nic wielkiego, IMHO).
Basile Starynkevitch
źródło
0

Pliki makefile nie są przestarzałe, podobnie jak pliki tekstowe nie są przestarzałe. Przechowywanie wszystkich danych w postaci zwykłego tekstu nie zawsze jest właściwym sposobem, ale jeśli wszystko, czego potrzebujesz, to lista rzeczy do zrobienia, zwykły plik tekstowy jest w porządku. W przypadku czegoś bardziej skomplikowanego możesz chcieć bardziej skomplikowanego formatu, takiego jak Markdown, XML lub niestandardowy format binarny lub cokolwiek pomiędzy, ale w prostych przypadkach zwykły tekst działa dobrze.

Podobnie, jeśli wszystko, czego chcesz, to sposób na uniknięcie ciągłego pisania, g++ -g src/*.c -o blah -W -Wall -Werror && ./blahMakefile odręczny jest idealny!

Jeśli chcesz zbudować coś, co jest wysoce przenośne, w którym nie musisz samodzielnie zarządzać tą przenośnością, prawdopodobnie chcesz, aby coś takiego jak Autotools wygenerowało odpowiedni Makefile dla Ciebie. Autotools wykryje funkcje obsługiwane przez różne platformy. Program napisany w standardzie C89 zbudowany z Autotools kompiluje się praktycznie wszędzie.

Miles Rout
źródło
„skompiluje się praktycznie wszędzie” -> „skompiluje się na najnowszych systemach uniksopodobnych”. Nie sądzę, autotoolsaby działał w jakimkolwiek istotnym stopniu w systemie Windows, na przykład (pomijając Cygwin / MingW, który tak naprawdę jest systemem uniksowym na Windowsie).
sleske,
Nie ma to nic wspólnego z aktualnością. Zaletą autotools jest to, że działa on na każdym zdalnym systemie podobnym do POSIX. Windows jest w pewnym stopniu zgodny z POSIX.
Miles Rout
Tak, poprawiam się. Właściwie pamiętam, że jedna krytyka autotools polega na tym, że zawiera on kod nawet dla bardzo starych systemów, więc podrap „najnowsze”. Jednak nadal jestem przy części dotyczącej systemu Windows.
sleske
A wina leży po stronie Microsoftu. Jeśli zależy im na wytworzeniu produktu wysokiej jakości, system Windows będzie miał odpowiednią obsługę międzynarodowych standardów systemów operacyjnych (takich jak POSIX). POSIX nie jest tylko „Unix rzeczą”, to przenośny standardowy system operacyjny dla wszystkich systemów operacyjnych. Windows to po prostu niepotrzebny stos śmieci.
Miles Rout
@MilesRout nadal jest taki, że „praktycznie wszędzie” wyklucza 90% komputerów stacjonarnych .
el.pescado,
-2

jeśli twój projekt jest prosty i zawiera bardzo mało plików, nie potrzebujesz pliku make.

Jednak gdy projekt jest złożony, wykorzystuje wiele obszarów pamięci, ma wiele plików, wówczas konieczne jest umieszczenie każdego obszaru pamięci we właściwym miejscu w pamięci adresowalnej, bardzo pożądane jest, aby nie kompilować każdego pliku za każdym razem, gdy trywialna zmiana jest wykonane do jednego pliku,

Jeśli chcesz usunąć stare pliki / kompilować / link / zainstalować przy minimalnej ilości kłopotów i szansy na błędy przy naciśnięciu klawisza, plik makefile jest prawdziwym dobrodziejstwem.

Kiedy wchodzisz do „prawdziwego świata”, projekty rzadko kiedy mają tylko 1 lub 2 pliki, a raczej setki plików. plik makefile zawsze wykona właściwe działania i nie będzie niepotrzebnych działań (po debugowaniu), więc wpisujesz tylko jedno proste polecenie, a plik makefile wykonuje całą pracę

użytkownik3629249
źródło
1
Że nie odpowiedział dlaczego wolą makenad cmakelub vice versa.
Ext3h
Korzystanie z makefiles nie powoduje przebudowy wszystkich plików za każdym razem. (w przeciwnym razie CMake lub Auto-narzędzia nie mogłyby go użyć)
ideasman42