Załóżmy, że uruchomiłem ./configure i make, ale teraz chcę zmienić parametr w skrypcie konfiguracyjnym. Czy muszę uruchomić make clean przed ./configure, czy wszystko będzie w porządku, nawet jeśli nie?Czy muszę uruchamiać "make clean" przed ./configure podczas rekonfiguracji?
W wielu przypadkach wszystko może być OK, jeśli nie uruchomisz make clean, ale nie możesz zakładać, że tak będzie.
Przykład tego, co może pójść nie tak: flaga configure może dodać parametr -D do zmiennej CFLAGS lub DEFS, zamiast definiować ją przez config.h. Ta ostatnia dałaby twoim plikom C zależność od config.h, która z kolei zostanie zregenerowana po ponownym uruchomieniu configure. Ale w pierwszym przypadku, jeśli ponownie uruchomisz configure i zmienisz tę flagę, zestaw symboli #defined w twoich plikach C będzie różny, ale te pliki C nie zostaną ponownie skompilowane.
configure Skrypty są zaprojektowane do uruchamiania "poza drzewem". np. możesz utworzyć podkatalog build i uruchomić tam stamtąd, co (idealnie) wpłynie tylko na katalog build.
Jeśli używasz ./configure, przed uruchomieniem configure musisz ponownie uruchomić make clean - po prostu dla bezpieczeństwa. W przeciwnym razie, jeśli obawiasz się skutków ubocznych, poprawnie napisany pakiet autotools powinien umożliwić katalog budowania poza drzewem.
W jaki sposób mógłby pomóc katalog budowania poza drzewem, jeśli go nie usunę i po prostu ponownie uruchomię './Configure'? Co by było inaczej? W przeciwnym razie jest to dodatkowy krok, tak samo jak uruchomienie 'make clean'. – sashoalm
@sashoalm - uruchamianie 'make clean' lub' make distclean' jest jakoś czasochłonnym "wąskim gardłem" w rozwoju twojego projektu? Autotools są na tyle złożone, że nie wymagają "sprytnych" skrótów, które mogą być cokolwiek innego. –