Parametry msbuild

Kto choć raz skompilował solucję Discovery4 (z minimalnymi parametrami np. msbuild /p:flavor=DEBUG;memory=flash Solutions\Discovery4\dotNetMF.proj) nie mógł się zapewne nadziwić, jak coś można z tych szlaczków, co przelatują na ekranie, wyczytać. Ekran przypomina coś takiego...

Aha! Nie do końca. Pięć ekranów wcześniej był żółty, a 2 ekrany wcześniej czerwony. Czy idzie to jakoś ogarnąć? Tak. Potrzebne są dodatkowe parametry. Po kolei.

Właściwości projektu to np. /p:flavor=debug;memory=flash. Zamiast debug możemy użyć następujących wartości: instrumented, release, rtm. Do końcowych wersji CLR powinniśmy użyć release lub rtm.

Elementy docelowe projektu to np: /t:build. Jest to domyślna wartość. Pozwala przyrostowo kompilować solucję. Gdy coś testujemy, dodając elementy do solucji, lub wyskoczy błąd kompilacji to ta opcja najszybciej skompiluje nam ponownie. Do czystej kompilacji powinniśmy użyć wartości /t:clean;build.

Plik projektu do kompilacji to np. Solutions\Discovery4\dotNetMF.proj. W tym przypadku zostanie skompilowany TinyBooter, a następnie TinyCLR. Nic nie stoi jednak na przeszkodzie, aby kompilować tylko pojedyncze projekty. Najczęściej kompiluje się TinyCLR. Czyli powinniśmy użyć takiego projektu Solutions\Discovery4\TinyCLR\TinyCLR.proj. Jak chcemy skompilować tylko TinyBooter to Solutions\Discovery4\TinyBooter\TinyBooter.proj.

Teraz opcje loggera. Parametry logowania konsoli określa się przełącznikiem /clp. Na przykład, aby nie pojawiały się na konsoli żadne informacje można użyć /clp:Verbosity=quiet. Przecież i tak nic z tego co w "czarnym okienku" się pojawia nie jesteśmy w stanie ogarnąć. Wartości jakie możemy użyć w verbosity to: quiet, minimal, normal, detailed i diagnostic. Możemy też skorzystać z dodatkowych opcji np. ErrorsOnly, WarningsOnly i Summary. Pierwsze dwa włączają pokazywanie tylko określonych komunikatów, a trzeci wskazuje czy na końcu ma pokazać podsumowanie. Summary działać będzie tylko wówczas, gdy Verbosity>=normal i nie będzie parametrów ErrorsOnly i WarningsOnly. Według mnie najlepszymi parametrami dla loggera konsoli to /clp:ErrorsOnly;Verbosity=quiet.

Jednak na wypadek błędu pasowałoby mieć jakieś informacje, co poszło nie tak. Możemy włączyć logowanie do pliku. Dzięki przełącznikowi /fl w katalogu, z którego odpalamy msbuild, powstanie plik msbuild.log. Dla tego loggera możemy wskazać takie same parametry, jak dla loggera konsolowego np.: /fl /flp:Summary;Verbosity=normal.

Dodatkowe parametry jakie możemy dodać do polecenia to /nologo - nie pokazuje informacji o wersji msbuild i /m - pozwala użyć do kompilacji wiele procesów. Na koniec otrzymamy więc takie polecenie:

msbuild /t:build /p:flavor=release;memory=flash Solutions\Discovery4\TinyCLR\TinyCLR.proj /clp:ErrorsOnly;Verbosity=quiet /fl /flp:Summary;Verbosity=normal /nologo /m

Najlepiej jednak zrobić sobie plik bat w katalogu PK na przykład z taką zawartością:

rem Discovery4 build script
call setenv_gcc 4.6.2 c:\gcc46
msbuild /t:build /p:flavor=release;memory=flash Solutions\Discovery4\TinyCLR\TinyCLR.proj /clp:ErrorsOnly;Verbosity=quiet /fl /flp:Summary;Verbosity=normal /nologo /m
pause