Czy CMake może generować skrypty budujące, które * nie * używają cmake?

Pytanie: Czy program CMake może generować skrypty budujące, które w żaden sposób nie korzystają z CMake? Jeśli nie, jak trudno jest wykasować skrypt automake wygenerowany przez CMake, aby nie przeprowadzać żadnych kontroli przeciwko CMake?Czy CMake może generować skrypty budujące, które * nie * używają cmake?

Jestem wielkim fanem CMake do tego stopnia, że jestem zwolennikiem idei, że przechodzimy do niego w moim obecnym środowisku pracy. Jedną rzeczą, która mogłaby ułatwić przejście z naszego obecnego systemu kompilacji do CMake byłby, gdybym mógł pokazać, że CMake może generować pliki automake, które same nie wymagają cmake.

Oczywiście, nigdy nie chciałbym tego robić na co dzień, ale posiadanie możliwości łatwego tworzenia gałęzi kodu, który można zbudować ze źródła, nie wymagając cmake, znacznie ułatwiłoby mi walizka.

Źródło

2010-07-09 Voltaire

Uważam za dziwne, że odpowiedzi tutaj są "nie". Po prostu dochodzę do punktu z cmake, że zaczynam rozumieć, jak go używać (zamiast próbować zmusić go do zrobienia czegoś, do czego nie jest przeznaczony), na przykład używając kompilacji out-of-source itp. Ale ja wiedzieć, że cmake jest dołączony do pakietu cpack, który może generować tarballe na Linuxie i podobne. Jeśli tarball wymaga zbudowania cmake, nie jestem przekonany, że jest to w ogóle tarball. – Steve314

Przyjrzę się bliżej CPack;) – Voltaire

Paczki generowane przez CPack zwykle nie są paczkami źródłowymi do budowania, lecz raczej binarnymi paczkami do uruchamiania systemu. – JesperE

Nie, CMake nie może tego zrobić. To naprawdę nie ma sensu, ponieważ bez wsparcia CMake w czasie kompilacji, nie byłoby sposobu, aby sprawdzić lub zaktualizować pliki Makefile/Project-Files, gdy pliki CMakeLists.txt uległy zmianie.

Jeśli przenosisz się z Visual Studio do CMake, możesz rzucić okiem na vcproj2cmake.

Źródło

2010-07-12 07:44:31 JesperE

To jest właściwie "pożądana" konsekwencja - jestem zainteresowany generowaniem automatycznych narzędzi typu "gotowy do dystrybucji" rodzaju buildu, gdzie make może być użyty do zbudowania projektu bez zależności cmake - w tym momencie jest ok jeśli zmiany nie zostaną odzwierciedlone ponownie w CMake. – Voltaire

Jest to przypadek użycia, którego CMake nie uwzględnia. – JesperE

Jako ktoś, kto wziął duży, złożony program i niedawno wyjął istniejący system kompilacji, instalując w jego miejsce nowy system kompilacji. Mogę powiedzieć, że to nie jest łatwe, ale zdecydowanie nie chciałbym, aby skrypty powłoki były częścią mojego procesu budowania, jeśli można ich uniknąć. Coraz więcej systemów znajdzie się na nich z CMake'em, ponieważ coraz więcej popularnych pakietów oprogramowania, takich jak LLVM i KDE, zaczyna z niego korzystać - to obszar, w którym naprawdę pasuje, duże projekty.

Jedną z fajnych rzeczy na CMake jest to, że buduje rzeczy szybciej. Nakazywanie namierzania instancji powłoki w celu interpretacji skryptu naprawdę spowalnia proces budowania.

Źródło

2010-07-09 22:47:34 jer

Pliki generowane przez CMake zależą od cmake dla różnych poleceń, takich jak create/remove/etc ... nie tylko w celu regeneracji plików Makefile przy zmianie, więc usunięcie cmake nie zadziała.

Źródło

2010-09-06 19:50:27 Oliver

+1 CMake może być również używany jako język skryptowy (patrz opcja "-P" na stronie podręcznika CMake), a wiele projektów korzysta z CMake jako zamiennika dla skryptów powłoki, takich jak kopiowanie plików dookoła lub wywoływanie programów pomocniczych. Projekty te będą wymagać CMake w czasie kompilacji, nie tylko do generowania pliku Makefile. – sleske

-1

Co z rozwiązaniem "atomowym"?

EX automatycznie wygenerować plik "QT moc" z CMakeLists.txt, a następnie zbudować projekt, który zależy od pliku .cpp generowany

# inside project level CMakeLists.txt 
# run shell script to create the "moc_GUICreator.cpp" auto-generated source file 
if(UNIX) 
execute_process(COMMAND "sh" ${CMAKE_CURRENT_SOURCE_DIR}/scripts/generate_moc.sh WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/scripts) 
endif(UNIX)

Jeżeli plik .sh zawiera:

# generate_moc.sh 
echo "generating moc file: moc ../include/GUICreator.h -o ../src/moc_GUICreator.cpp " 
moc ../include/GUICreator.h -o ../src/moc_GUICreator.cpp

odpowiednik Windows plik wsadowy "moc_creator_win.bat":

moc "GUICreator.h" -o "moc_GUICreator.cpp"

nie próbowałem tego l nieco ast w oknach, ale czy coś powinno działać bardzo blisko, tuż po if (UNIX) bloku w CMakeLists.txt:

if(WIN32) 
execute_process(COMMAND "cmd" ${CMAKE_CURRENT_SOURCE_DIR}/scripts/moc_creator_win.bat WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/scripts) 
endif(WIN32)

Więc w zasadzie, jeśli jesteś mądry możesz robić, co chcesz z skryptuj i używaj zmiennych CMake jako argumentów, nie jestem pewien, czy możesz poprosić o więcej ...

chodzi o to, aby uniknąć „non-przenośne typu build”, chyba że naprawdę musisz włamać się do wyspecjalizowanego kompilatora, czy nie czuje się jak za pomocą Qt Designer umieszczać widżety ;-)

Źródło

2010-09-23 08:42:19

Nie jestem pewien, czy jest to istotne dla pierwotnego pytania. –

Punkt, w którym możesz użyć CMake zgodnie z przeznaczeniem lub na przeciwległym końcu spektrum, po prostu owinąć go wokół dowolnych skryptów. Nic nie powstrzyma cię przed analizowaniem zmiennych cmake i generowaniem plików makefiles, których pragniesz ... –

Zdolność aby to zrobić, zależy od twojego systemu operacyjnego, domyślam się Unix/Makefile lub Winderz/MSVC. Jeśli używasz MSVC, zależność cmake powinna zostać wyeliminowana poprzez zadeklarowanie opcji CMAKE_SUPPRESS_REGENERATION na początku twojego skryptu cmake.

SET(CMAKE_SUPPRESS_REGENERATION TRUE)

W systemach uniksowych, jednak Makefile są tied wyraźnie do CMake zbudować plików (CMakeFiles, etc). Podejrzewam, że tę zależność można ominąć przez strategiczne komentowanie dyrektyw Makefile, chociaż nie mogę powiedzieć, czym one są.

Źródło

2011-08-19 09:24:55

Czy CMake może generować skrypty budujące, które * nie * używają cmake?

Odpowiedz

Powiązane problemy