Wpis z mikrobloga

Treść przeznaczona dla osób powyżej 18 roku życia...
  • 8
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@Rasteris: ale z drugiej strony jak masz np. dokumentację to nie chcesz żeby przerzucał. A te skrypty są dość zdolne, pamiętam żeśmy się z nich automatycznie łączyli z targetem po ssh i robili cuda-wianki.
Samo kopiowanie jest takim sobie pomysłem. Tradycyjne make buduje in-tree i wtedy masz pliki i nie zjadasz więcej miejsca na dysku.
  • Odpowiedz
@keton22: a co to za problem, żeby można było oznaczyć katalog, który jest do przerzucenia? W czasie pisania to chyba najlepiej się sprawdzi ln -s ( ͡° ͜ʖ ͡°)
  • Odpowiedz
@Rasteris: a widzisz a ja bym wolał zaznaczyć :) Może dlatemu że pliki z danymi które mamy w repo są spore ale idą do bazy a nie bezpośrednio na wejście. Co usecase to inne wymagania. W takim układzie na moje lepsza opcja to nic nie robić bo jak target to embedded to może nawet nie pomieścić a stworzysz plik, zapomnisz odznaczyć i będziesz się dziwił że system zdechł.
  • Odpowiedz
@keton22: ja akurat nie mam dużych plików, ale kilka ich jest. Na upartego mógłbym wrzucić to w program, a nie osobne pliki, ale to taka gierka ekonomiczna i potem łatwiej będzie w ten sposób robić balans gry, pogrzebać w plikach zamiast robić kompilacje co chwila.
A takie rzeczy mnie wkurzają, bo zamiast skupić się na algorytmach, które będą dość zakręcone muszę bawić się z implementacją w kodzie rzeczy drugoplanowych dla
  • Odpowiedz
@Rasteris: Ideą Qt, jest zapakować wszystkie dodatkowe pliki do qrc, które się doda do binarki jako zasób. To działa automatycznie. Jednak jak chcemy trzymać zasoby w odzielnych plikach bądź paczkach rc, to niestety trzeba sobie samemu ręcznie dopisać buildstep do qmake. Ja tak miałem zrobione pliki konfiguracyjne w JSONie dla których stworzyłem osobny buildstep, który merdżował wersje z gita i lokalną przy użyciu polecenia jq.
  • Odpowiedz