Używanie pliku Makefile z kabałą?

Question

pracuję nad projektem zabawki jako sposób przenieść moje zadowolenie z Haskell z teoretyczną z praktycznym, upewnij się bardziej komfortowo z cabal, HUnit itp

Właśnie dodałem Makefile do mojego projektu:

test: dist/build 
    cabal-dev test 

dist/build: dist/setup-config src/*.hs tests/*.hs 
    cabal-dev build 
    touch dist/build 

dist/setup-config: ToyProject.cabal 
    cabal-dev configure --enable-tests 

Ponieważ:

• cabal-dev install --enable-tests wydawało się przesadą (i ostrzegał mnie ponownie instaluje)
• cabal-dev configure --enable-tests && cabal-dev build && cabal-dev test robił niepotrzebnej pracy, a utrzymanie stanu, czy musiałem przekonfigurować był nudny
• i oba były dużo wpisując

obawiam się, że mogę być odtwarzając funkcjonalność sprawi że cabal lub cabal-dev już daje mi, ale nie jestem dostatecznie obeznany, aby wiedzieć, czy to prawda, a jeśli tak, to jak bym to zrobił.

Czy plik Makefile jest odpowiedni tutaj, czy jest bardziej bezpośredni sposób na zrobienie tego tylko za pomocą cabal/cabal-dev?

Answer 1

Poniżej jest uproszczoną wersją Makefile używam z pakietem Cabal Zajmuję się równolegle z innym programem Haskell, który zależy na opakowaniu Cabal (I często edytować je równolegle i tak mam Cabal pakiet jako zależność programową od programu, przy użyciu innego pliku Makefile: P) . Celami są:

1. Uruchom tylko cabal, jeśli niektóre pliki źródłowe się zmieniły. I użyj tego pliku Makefile na powolnym netbooku bardzo, w którym etap rozwiązywania zależności w Cabal zajmuje 10 sekund sekund, więc chcę, aby w ogóle nie działał cabal install.

2. Masz niezależne debugowanie i regularne kompilacje w oddzielnych kompilacjach katalogów. Domyślnie, jeśli zrobisz kompilację Cabal z profilowaniem (--ghc-options=-fprof-auto), a następnie bez profilowania,Cabal rozpocznie się od nowa, rekompilując wszystkie pliki od zera. Umieszczenie kompilacji w oddzielnych katalogach kompilacji pozwala uniknąć tego problemu.

Nie jestem pewien (2) jest dla Ciebie interesująca, ale (1) prawdopodobnie jest i widzę że tylko dotknąć dir bazować na sukcesie, a nie porażki, i spodziewam się, że nie będzie działać poprawnie.

Oto Makefile:

cabal-install: dist 

cabal-install-debug: prof-dist 

# You will need to extend this if your cabal build depends on non 
# haskell files (here '.lhs' and '.hs' files). 
SOURCE = $(shell find src -name '*.lhs' -o -name '*.hs') 

# If 'cabal install' fails in building or installing, the 
# timestamp on the build dir -- 'dist' or 'prof-dist', stored in 
# the make target variable '$@' here -- may still be updated. So, 
# we set the timestamp on the build dir to a long time in the past 
# with 'touch --date "@0" $@' in case cabal fails. 
CABAL_INSTALL = \ 
    cabal install $(CABAL_OPTIONS) \ 
    || { touch --date "@0" $@ ; \ 
     exit 42 ; } 

dist: $(SOURCE) 
    $(CABAL_INSTALL) 

# Build in a non-default dir, so that we can have debug and non-debug 
# versions compiled at the same time. 
# 
# Added '--disable-optimization' because '-O' messes with 
# 'Debug.Trace.trace' and other 'unsafePerformIO' hacks. 
prof-dist: CABAL_OPTIONS += --ghc-options="-fprof-auto" --builddir=prof-dist --disable-optimization 
prof-dist: $(SOURCE) 
    $(CABAL_INSTALL)