testowanie perla po zainstalowaniu

Question

Podczas budowania perla ze źródła, masz możliwość uruchomienia make test przed instalacją perla w miejscu docelowym.

Czy można zainstalować odpowiednik make test po zainstalowaniu perla?

Pamiętaj, że nie będę mieć oryginalnego źródła. Chciałbym pobrać źródłowe archiwum tar dla tej samej wersji perla, którą zainstalowałem, a następnie uruchomić testy (ze źródłowego archiwum tar) przeciwko zainstalowanemu perlowi.

Możliwe/niemożliwe? Łatwe trudne? Jak bym to zrobił?

Answer 1

Możesz rozpocząć od odczytania pliku t/TEST w kodzie źródłowym perla.

Wskazówka następujące:

1. Używa "# ./ perla!" Jako she-hukiem

2. Następnie na około 142 linii, to jednak przejście do katalogu katalogu t.

Na początek można modyfikować że linia ona bang aby skierować go do zainstalowanego perl wykonywalny i skopiuj zawartość „t” katalogu do katalogu podstawowe pakiety Perl (lub na odwrót) .

Tak zacznę.

Innym sposobem jest utworzenie listy wszystkich zainstalowanych plików po uruchomieniu make install (spraw, aby instalował perl w katalogu tymczasowym, a następnie wykonaj ls -lR w tym katalogu, aby znaleźć na liście), a następnie skopiuj pliki z zainstalowanego perla do katalogu ze źródłami perla.

Korzystanie z systemu kontroli wersji (na przykład git) może wiele pomóc, abyś mógł łatwo wrócić do nieskazitelnej wersji plików, które mogłeś nadpisać po drodze.

Answer 2

• Możliwe.
• Trudno.
• Nie warto.

Prowadzenie badań z zainstalowaną Perl zamiast po prostu zbudowany Perl będzie wymagać, aby zrozumieć, w jaki sposób przekonać do systemu testowego zignorować cały build nie zrobić i dostać się na prowadzenie badań, przy użyciu zainstalowany Perl. Nie można powiedzieć "make test", ponieważ pierwszą rzeczą, którą chciałby zrobić, jest zbudowanie Perla. W rzeczywistości, bardziej do rzeczy, nie można powiedzieć "make test", ponieważ nie masz pliku Makefile.

Dlaczego chcesz to zrobić? Jeśli nie ufasz systemowi Perl, nie używaj go. Zbuduj swój własny, przetestuj go i zainstaluj w swojej lokalizacji zamiast w lokalizacji systemowej. Robię to przez większość czasu; Nie ryzykuję zerwania Perla systemu, modyfikując go i używając własnego. Oczywiście mam 5.10.0, 5.10.1, 5.12.1, 5.14.0 i 5.14.1 zbudowany (przeze mnie) do grania. Zwykle mam też co najmniej jedną wersję 5.8.x, ale nie na tym komputerze.

Pamiętaj też, że ludzie instalujący system Perl są przy zdrowych zmysłach. Przeprowadzają testy i nie instalują Perla, chyba że wszystkie testy zakończą się pomyślnie (lub zasadniczo wszystkie).

Answer 3

możliwe, tylko trochę twarde (nie Configure lub make konieczne), może być przydatna:

Program testowy w dystrybucji ładunków źródłem wszystkiego z katalogu lib` katalog /path/to/src/distribution/lib'. The key to running your existing perl installation against this test suite is to put all of the install libraries into this. Można to zrobić z czymś takim:

cd /path/to/src/distribution 
mv lib lib-original 
mkdir lib 
/path/to/installed/perl -e 'system qq{cp -prv "$_/." lib/}' \ 
     -e 'for "lib-original",grep /../,reverse(@INC)' 

(tam chyba bardziej wytrzymałe perl poleceń, które używa -MFile::Copy, ale to szybki i-brudny jeden-liner got me going). Używamy reverse @INC, więc biblioteki z przodu @INC nadpiszeją późniejsze biblioteki, a nie odwrotnie. Klauzula grep /../,... uniemożliwia nam skopiowanie . do, co prawdopodobnie nie byłoby pomocne.

Znalazłem kilka testów, które używają zakodowanych ścieżek do perl, psed i s2p w katalogu źródłowym. Będziesz chciał upewnić się, że te pliki istnieją i że testy są ukierunkowane na zainstalowane wersje tych programów.

rm -f perl t/perl psed t/psed x2p/s2p 
ln -s /path/to/installed/perl perl 
ln -s /path/to/installed/perl t/perl 
ln -s /path/to/installed/psed psed 
ln -s /path/to/installed/psed t/psed 
ln -s /path/to/installed/s2p x2p/s2p 

Teraz użyj zwykłego Unix-y idiom na prowadzenie Perl testową Suite:

cd t 
/path/to/installed/perl -MExtUtils::Command::MM \ 
     -e 'test_harness(0,"../lib")' */*.t 

Niektóre testy mogą być wyraźnie o sprawdzenie integralności procesu build-z-source, więc niektóre awarie należy się spodziewać.

(proces ten testowany na v5.14.0, v5.8.9, v5.10.1)

Aktualizacja: jeszcze trudniejsze. Istnieje wiele innych katalogów t wewnątrz typowej dystrybucji źródłowej. Prawdopodobnie też chcą wypróbować:

cd /path/to/source/distribution 

for dir in */*/ 
do 
     if [ -d $dir/t ] ; then 
      pushd $dir 
      echo Testing $dir 
      /path/to/installed/perl -MExtUtils::Command::MM \ 
        -e 'test_harness(0,"../../lib","lib")' t/*.t 
      popd 
     fi 
done 

Wiele z tych testów są wyraźnie testowania integralności konstrukcji, więc można się spodziewać wiele z tych prób się nie powiedzie.