ant+cpptasks vs. scons vs. make

Używałem Ant + CppTasks mocno kilka lat temu do budowania bardzo dużych baz kodu zintegrowanych z nowym kodem Java poprzez JNI i byłem bardzo zadowolony z wyników bardzo niezawodnych przyrostowych kompilacji kodu C++, dobrej elastyczności (w plikach kompilacji lub poprzez poprawki do kodu). Ale CppTasks jest projektem bez społeczności, a opiekun (Curt Arnold) od dawna nic z nim nie robił. Pozostaje bardzo dobry i przydatny, ale należy pamiętać, że bardzo niewiele osób zna lub używa CppTasks (sposób, w jaki Kompilatory "licytują" pliki gryzą mnie na przykład, gdy potrzebowałem konkretnego kompilatora dla plików C, a inny kompilator C++ odbierał je zamiast tego).

Sposób, w jaki CppTasks śledzi opcje kompilacji i dynamicznie skanuje źródła w poszukiwaniu zależności nagłówka, przez cały czas, ale wystarczająco szybko( jest trochę buforowania zależności), oznaczał, że jedyny system, z którym pracowałem, miał dokładne przyrostowe Kompilacje, coś bardzo ważnego podczas budowania bardzo dużego kodu bazy.

Więc jak już mówiłem kilka razy na listach Ant user/dev, jeśli masz dużo rzeczy Java i już zainwestowałeś w Ant, i nie boisz się zanurzyć w DOC i kod CppTasks, a teraz musisz zbudować kod JNI "glue" i/lub "legacy" natywne biblioteki, które kod glue eksponuje, jest to wartościowa rywalizacja, a nagrody mogą być świetne.

I łatwo zintegrować Dla dll Windows, aby dodać pełną wersję informacji, na przykład, pisząc little Ant zadanie do formatowania .plik res poprawnie. U mnie działało, ale Ant + CppTasks jest zdecydowanie bardziej dla "zaawansowanego" użytkownika / dewelopera Ant IMHO.

Mam nadzieję, że to pomoże. -- DD

Chciałbym polecić terp do budowania projektów C++ z ANT. Stworzyliśmy terp, ponieważ ANT jest naszym wybranym narzędziem do budowania, a zadania Cppt były coraz dłuższe w zębie i dlatego, że chcieliśmy pracować na innym poziomie abstrakcji. terp obsługuje wiele różnych kompilatorów i jest obsługiwany przez naszą firmę. W przypadku większości projektów nie jest to jednak bezpłatne.

Zaprojektowaliśmy terp głównie dla pełnych przebudów, a nie przyrostowych kompilacji z analizą zależności. Jesteśmy dojazd, ale jeszcze go nie ma. Sweet spot dla terp jest w wydaniach wieloplatformowych, multi-procarch, multi-kompilatorów, gdzie nie chcesz utrzymywać n różnych konfiguracji dla wszystkich kombinacji. W tym momencie (lipiec ' 09) jest w publicznej wersji beta, ale wkrótce zostanie wydany.

Pracowałem nad projektem przez ostatnie pięć lat, który tworzy x86 i ARM przy użyciu ant. Poprawiliśmy cpptasks do naszych celów, aby stworzyć ogólny kompilator, który po prostu przekazujemy w prefiksie do...np. arm-gum-linux-gnueabi - a potem to zostaje dodane do rzeczywistego narzędzia np. g++ czy ar czy jakoś tak. Brak prefiksu oznacza, że dostajesz narzędzia do budowania platform programistycznych. Łańcuchy narzędzi do kompilacji krzyżowej mają te prefiksy w swoich binariach narzędzi budowania. Prawie cały powód do pójścia z Ant a nie cokolwiek make oparte było cpptasks zdolność do robienia inremental buildy i uttter plątaniny rzeczy, które muszą się zdarzyć, aby utrzymać autoconf szczęśliwy. Jesteśmy w stanie wspierać paradygmat, że prawie każdy plik źródłowy, szczególnie te w strukturze drzewa folderów dla zestawu bibliotek, może być utworzony/przemianowany/usunięty i nie ma potrzeby wprowadzania zmian do plików kompilacji. Jedną małą wadą jest to, że łączenie plików aktualizuje właściwości w sposób, który spowoduje niepotrzebną przebudowę.

<target name="lib.cvp">
<fetch.and.log.version 
    svnvers.target="common/cvp" 
    svnvers.property="libcvp.version"/>
    <cc objdir="${obj.dir}/common/cvp" 
        commandPrefix="${command.prefix}" 
        compilerName="${compiler.name}"
        outfile="${lib.dir}/cvp" outtype="static">
        <compiler extends="base.compiler"/>
        <compilerarg 
            value="-D__CVP_LIB_BUILD_VERSION__=&quot;${libcvp.version}&quot;"/>
        <compilerarg 
            value="-D__BUILD_NOTES__=&quot;${libcvp.toolversion}&quot;"/>
        <compilerarg if="is.x86" value="-DARCH_X86"/>
        <linker extends="base.linker"/>
        <includepath refid="common.inc"/>
        <fileset dir="${project.home}/common/cvp">
            <include name="*.c"/>
            <include name="*.cpp"/>
        </fileset>
    </cc>
</target>

Ant ma bardzo dużą bazę użytkowników Javy (z przyczyn naturalnych). Fakt, że Ant może być bardzo przydatny w znacznie szerszym otoczeniu, jest czymś, czego większość programistów spoza Javy nie jest świadoma. W rezultacie, jeśli używasz Ant zbudować swój C / C++-kod znacznie więcej na własną rękę, że jeśli używasz systemu z większą bazą użytkowników (CMake lub SCons).

Osobiście byłem bardzo zadowolony z CMake, przede wszystkim dlatego, że jest to jedyny system budowania, który może generować prawdziwe Projekty Visual Studio. Bułeczki też mogą, ale wykonują tylko zewnętrzne wywołanie do SCons, podczas gdy CMake generuje projekty, które wykorzystują własny silnik budowania Visual Studio. Jest to bardzo przydatne, jeśli pracujesz razem z ludźmi, którzy są przyzwyczajeni do Visual Studio.

Nie jestem pewien, czy nazwałbym wsparcie CMake dla crosscompilation "dojrzałym", ponieważ wciąż jest dość młody. Ale ludzie z CMake traktują to poważnie, więc nie wahałbym się go wypróbować.