[OT] Zarządzanie konfiguracją modułów ko du źródłowego

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Polish to

Threaded View
PrzedstawiC4%99 najpierw scenariusz oraz problem:

Mamy bibliotekC4%99 moduC5%82C3%B3w kodu C5%BArC3%B3dC5%82owego, k=
tC3%B3re sC4%85 uC5%BCywane w wielu  =

projektach. KaC5%BCdy z moduC5%82C3%B3w ma swoje parametry konfigurac=
yjne, ktC3%B3rymi  =

moC5%BCna go "dostroiC4%87" dla potrzeb konkretnej aplikacji i pC5%82=
ytki - np. moduC5%82  =

bC4%99dC4%85cy driverem do scalaka radiowego ma m.in. parametry okreC5%
9B%lajC4%85ce do  =

jakich pinC3%B3w procesora scalak jest podpiC4%99ty, moduC5%82 bC4%99=
dC4%85cy driverem do  =

pamiC4%99ci na I2C ma parametry mC3%B3wiC4%85ce ktC3%B3rym interfejs=
em I2C mikrokontrolera  =

naleC5%BCy z tC4%85 pamiC4%99ciC4%85 rozmawiaC4%87, jaki jest rozmi=
ar pamiC4%99ci i ktC3%B3ry pin  =

procesora to CS, itp.

Problem:
W kaC5%BCdym projekcie, ktC3%B3ry korzysta z danego moduC5%82u, ustaw=
iamy odpowiednio  =

wszystkie parametry. NastC4%99pnie, z dowolnej przyczyny, w bibliotece =
 =

zmieniamy zestaw parametrC3%B3w konfiguracyjnych oferowanych przez modu=
C5%82. W  =

efekcie musimy poprawiC4%87 pliki konfiguracyjne w kaC5%BCdym z projek=
tC3%B3w, co przy  =

rosnC4%85cej liczbie tych projektC3%B3w po chwili staje siC4%99 boleC5%
9B%nie pracochC5%82onne.

Szukam mC4%85drej metody radzenia sobie z tC4%85 niepotrzebnC4%85 pra=
cC4%85. Metody  =

aplikowalnej do kodu w C i assemblerze (choC4%87 bardzo chC4%99tnie us=
C5%82yszC4%99, jeC5%9Bli  =

w C++ da siC4%99 to zrobiC4%87 jakoC5%9B lepiej). WaC5%BCne, aby met=
oda nie powodowaC5%82a  =

skutkC3%B3w run-time (np. zamiast ustalaC4%87 rozmiar pamiC4%99ci w k=
onfiguracji, mogC4%99  =

mieC4%87 zmiennC4%85 ustawianC4%85 w funkcji inicjalizujC4%85cej, do=
 pinC3%B3w mogC4%99 mieC4%87  =

callbacki wC5%82C4%85cz/wyC5%82C4%85cz, teC5%BC ustawiane przez API=
, a do sprzC4%99towego moduC5%82u  =

I2C mogC4%99 mieC4%87 dodatkowC4%85 warstwC4%99 abstrakcji, ale wszy=
stko to kosztuje  =

pamiC4%99C4%87 lub cykle, a w przypadku niektC3%B3rych parametrC3%B3=
w jest praktycznie  =

niewykonalne - poza tym tylko to przesuwa problem ze zmian konfiguracji,=
  =

na zmianC4%99 API).

Jestem blisko rozpoczC4%99cia pisania programu, ktC3%B3ry bC4%99dzie =
mi zarzC4%85dzaC5%82 tC4%85  =

konfiguracjC4%85, tzn. za jednym klikiem porC3%B3wna konfiguracje wszy=
stkich  =

zarzC4%85dzanych projektC3%B3w, pokaC5%BCe gdzie sC4%85 nieustawione=
 parametry, gdzie sC4%85  =

ustawione juC5%BC nieistniejC4%85ce parametry, gdzie wartoC5%9BC4%87=
 parametrC3%B3w rC3%B3C5%BCni siC4%99  =

od domyC5%9Blnej, a nastC4%99pnie umoC5%BCliwi wybranie akcji, ustawi=
enie wC5%82aC5%9Bciwych  =

wartoC5%9Bci i uaktualni zarzC4%85dzane pliki konfiguracyjne. Ale troc=
hC4%99 mam  =

nadziejC4%99, C5%BCe istnieje jakiC5%9B inteligentny sposC3%B3b, na =
ktC3%B3ry nie wpadC5%82em.

ae

Re: [OT] Zarządzanie konfiguracją modułó w kodu źródłowego
W dniu 06.05.2012 13:09, Andrzej Ekiert pisze:

Quoted text here. Click to load it

Na to nic nie poradzisz. Skoro biblioteka zmienia swoje
parametry/interface to musisz dostosować do niej programy.
W c++ od biedy można zastosować parametry domyślne albo przeciążyć
funkcje. Wtedy stare programy mogą korzystać ze starego interfejsu.

Quoted text here. Click to load it

A to już zwykłe makra, definy, funkcje inline, specjalizacje szablonów
nie wystarczą do ukrycia fizycznego położenia pinów?

Quoted text here. Click to load it

Jeśli do wszystkich modułów I2C z różnych procesorów jesteś w stanie
opracować jeden interface to nie ma problemu. Dodajesz do projektu plik
ze swoją obsługą I2C od danego procka i już. Moduł radiowy wykorzysta te
funkcje, które dołączy linker. Zero narzutu.


Ja raczej unikami uşywania tej samej kopii biblioteki do róşnych
projektów. Dasz sobie głowę uciąć, że zmiana w bibliotece pod bieżący
projekt x nie spowoduje jakiś anomalii w projekcie x-10, który pisała
inna osoba?
Wolę zrobić kopię biblioteki z projektu x-1 i nanieść poprawki.

Re: [OT] Zarządzanie konfiguracją modułów ko du źródłowego

Quoted text here. Click to load it

Quoted text here. Click to load it

WystarczC4%85, ale dla kaC5%BCdego projektu trzeba te define'y inaczej=
 ustawiC4%87 -  =

ta sama nazwa, inna wartoC5%9BC4%87.

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it
82% radiowy wykorzysta te  =

Quoted text here. Click to load it

Przy wielu architekturach, to akurat nie mam wyjC5%9Bcia i muszC4%99 z=
robiC4%87  =

takiego HALa, ale narzut jest. W przypadku jednej architektury, to zamia=
st  =

po prostu siC4%99 odwoC5%82aC4%87 do rejestru sprzC4%99towego moduC5%
82%u, muszC4%99 przekazaC4%87  =

mojemu driverowi do chipu jakC4%85C5%9B strukturC4%99 drivera do modu=
C5%82u I2C, ktC3%B3ra  =

bC4%99dzie mieC4%87 np. callbacki do funkcji poC5%9BredniczC4%85cych=
. Narzut jak diabli,  =

choC4%87 czasem trzeba siC4%99 na niego zgodziC4%87 (np. wspC3%B3dzi=
elony dostC4%99p kilku  =

"driverC3%B3w" do jednego sprzC4%99towego I2C).

Quoted text here. Click to load it
BC%nych  =

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Staram siC4%99 tak modularyzowaC4%87 kod i dawaC4%87 takie API, C5%BC=
eby zmiany nie  =

wywoC5%82ywaC5%82y efektC3%B3w ubocznych. OczywiC5%9Bcie przetestowa=
C4%87 to zawsze trzeba i  =

nie dam sobie uciC4%85C4%87 nawet paznokcia.

Quoted text here. Click to load it

Wykrywasz bC5%82C4%85d albo robisz usprawnienie w x-1 i dopiero masz p=
oprawianie  =

wszC4%99dzie gdzie ta kopia jest. Brrr...

ae

Re: [OT] Zarządzanie konfiguracją modułó w kodu źródłowego
W dniu 06.05.2012 14:55, Andrzej Ekiert pisze:
Quoted text here. Click to load it

Zgadza się i zakładam, że rzeczy specyficzne dla projektu trzymasz w
osobnym pliku, ktĂłry leĹźy sobie w katalogu z projektem i jest przez
bibliotekę tylko includowany. Zgadza się?


Quoted text here. Click to load it

Ja jak na razie na I2c wieszałem jakieś pamięci, RTC itp. badziewie. Do
jego obsługi wystarczały mi 3 funkcje typu wyślij blok danych, odbierz
blok danych, sprawdź gotowość. Współdzielenie zabezpieczałem mutexami.
Funkcje RTC czy obsługa pamięci wprost wołały te funkcje. W innym procku
dodawałem tylko inną bibliotekę do I2c. Interface zostawał ten sam. Zero
narzutu.

Quoted text here. Click to load it

To jest niewątpliwie wada. Ale powiedzmy sobie szczerze, ile można
spieprzyć w kodzie obsługi I2C, uarta itp?
A teraz weź projekt sprzed kilku lat (bo klient chce drobną poprawkę) i
skompiluj go z nową biblioteką. Jaką masz gwarancję, że nie wyjdą jakieś
wredne bugi związane np. z zależnościami czasowymi?

Re: [OT] Zarządzanie konfiguracją modułów ko du źródłowego

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Tak.


Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Masz driver do RTC w bibliotece. Procesor ma 2 moduC5%82y sprzC4%99tow=
e I2C1 i  =

I2C2. Musisz przekazaC4%87 driverowi RTC informacjC4%99, funkcje dotyc=
zC4%85ce ktC3%B3rego  =

moduC5%82u ma wywoC5%82aC4%87: odbierz_blok_danych_z_I2C1() czy  =

odbierz_blok_danych_z_I2C2(). Albo to robisz na poziomie #define, albo  =

definiujC4%85c "driver" do I2C i przekazujC4%85c moduC5%82owi I2C han=
dle do tego  =

drivera (jest narzut). Ja chcC4%99 na poziomie #define, ale pragnC4%99=
 sobie  =

usprawniC4%87 zarzC4%85dzanie takimi #define.

Quoted text here. Click to load it
9B%C487% poprawki.
Quoted text here. Click to load it
BC%na  =

Quoted text here. Click to load it

SpieprzyC4%87 zawsze moC5%BCna. Poza tym moduC5%82 moC5%BCe byC4%87=
 czymC5%9B bardziej zC5%82oC5%BConym.  =

Np. implementacjC4%85 protokoC5%82u sieciowego.

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Gwarancji nie mam, choC4%87 moja ciC4%85gC5%82a dbaC5%82oC5%9BC4%87=
 o to, by kawaC5%82ek kodu, w  =

ktC3%B3rym zaleC5%BCnoC5%9Bci czasowe wystC4%99pujC4%85, nie mC3%B3=
gC5%82 byC4%87 zakC5%82C3%B3cony przez inne  =

niezwiC4%85zane z nim moduC5%82y wykonywane rC3%B3wnolegle, daje mi s=
pore szanse.  =

Generalnie uwaC5%BCam, C5%BCe zysk ze wspC3%B3C5%82dzielonych biblio=
tek znacznie  =

przewyC5%BCsza koszty.

ae

Re: [OT] Zarządzanie konfiguracją modułó w kodu źródłowego
W dniu 06.05.2012 15:44, Andrzej Ekiert pisze:
Quoted text here. Click to load it

No to dużo więcej już nie wymyślisz. Co najwyżej możesz w przypadku
dokładania nowych stałych/parametrów napisać:

#ifndef XYZ
#define XYZ 12345
#endif

Wtedy biblioteka ze starym programem nie będzie krzyczała, że nie ma
zdefiniowanych parametrĂłw.

Quoted text here. Click to load it

No to użyj tego define. I tak jak podałem wyżej możesz zrobić domyślną
definicję dla starych programów.

Quoted text here. Click to load it
złożonym.
Quoted text here. Click to load it

Takie rzeczy jak protokół to już dla mnie warstwa wyższa :-) i tu nie
mam obaw o współdzielenie.

Re: [OT] Zarządzanie konfiguracją modułó w kodu źródłowego
Quoted text here. Click to load it
Ja właśnie rzeźbię powolutku coś takiego w C++, tylko zamiast callbacków
traits przekazywane do szablonów, żeby nie było żadnego narzutu w runtime.

Kompilator odwala całkiem niezłą robotę z funkcjami inline, np

HW::uart<0>::send_char(buf[i]);
zamienia na pojedynczy mov do rejestru.



--
Pozdrawiam
Michoo

Re: [OT] Zarządzanie konfiguracją modułó w kodu źródłowego
W dniu 06.05.2012 15:54, Michoo pisze:
Quoted text here. Click to load it

A jakie będą tego zalety w stosunku do wersji z define?

Re: [OT] Zarządzanie konfiguracją modułó w kodu źródłowego
Quoted text here. Click to load it
Że nie muszę kopiować kodu dla uart 1. No i środowisko mi ładniej
koloruje funkcje wpisane jako funkcje a nie jako połamane define.

Btw - jak będę miał dość czasu, żeby posprzątać kod to wrzucę go na
jakieś sourceforge i każdy będzie mógł ocenić.


--
Pozdrawiam
Michoo

Re: [OT] Zarządzanie konfiguracją modułó w kodu źródłowego
W dniu 06.05.2012 16:55, Michoo pisze:
Quoted text here. Click to load it

Póki rejestry UART są rozmieszczone identycznie względem bazowego, to w
zwykłym C napiszesz jedną obsługę do wszystkich UARTów bez żadnych
define'Ăłw.

Quoted text here. Click to load it

Chętnie zobaczę.

Re: [OT] Zarządzanie konfiguracją modułów ko du źródłowego

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

MoC5%BCliwoC5%9BC4%87 robienia czegoC5%9B takiego mnie mocno przekon=
uje do C++.

ae

Re: [OT] Zarządzanie konfiguracją modułó w kodu źródłowego
Quoted text here. Click to load it

Kopię? Od tego są systemy kontroli wersji. Robimy brancha nowego i
dostosowujemy. Jak coś się zmieni w głównej gałęzi (np straszny bug
wykryty) to mergujemy samą zmianę. W gicie robi się to pięknie...

Takie problemy występują podczas rozwoju każdego oprogramowania, warto
poczytać o schematach/rozwiązaniach przetestowanych w takim środowisku.

http://nvie.com/posts/a-successful-git-branching-model /

Marek

Re: [OT] Zarządzanie konfiguracją modułó w kodu źródłowego
Ja osobiście jestem na początku drogi - tj. jeszcze nie powstały te
dziesiatki modulow do dziesiatek aplikacji, ale zaczynam już dostrzegać
problem, stąd moje zainteresowanie tą problematyką - tak, aby zawczasu
coś ustalić i pisać dalej w/g ustalonej, optymalnej metody.

Jednym z pomysłów jest wykorzystanie programów do zarządzania wersjami
typu: SVN, GIT, Mercurial.
Innym pomysłem, który mnie zainteresował, jest wykorzystanie linków do
plikĂłw zamiast kopii plikĂłw (pod Linuxem) - w ten sposĂłb mamy tylko
jeden plik, widziany przez dowolnie wiele projektow i zmiana w nim
przenosi się automatycznie na wszystkie projekty.

Najprosciej byłoby nie zmieniać parametrow konfiguracyjnych w bibliotece
;-)
A może zostawić stare jako 'deprecated', a dodac do nich nowe?


--
Jado




W dniu 06.05.2012 13:09, Andrzej Ekiert pisze:
We've slightly trimmed the long signature. Click to see the full one.
Re: [OT] Zarządzanie konfiguracją modułów ko du źródłowego

napisaC5%82(a):

Quoted text here. Click to load it
85%dzania wersjami  =

Quoted text here. Click to load it

AleC5%BC ja to wszystko mam pod Mercurialem, tyle C5%BCe to tego probl=
emu akurat  =

nie rozwiC4%85zuje.

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Chodzi o to, C5%BCe dla kaC5%BCdego projektu mam te same parametry ust=
awione w  =

inny sposC3%B3b. WiC4%99c teC5%BC nie rozwiC4%85zuje problemu.

Quoted text here. Click to load it

Quoted text here. Click to load it

No rzeczywiC5%9Bcie :-)

ae

Re: [OT] Zarządzanie konfiguracją modułó w kodu źródłowego
Quoted text here. Click to load it

Zapropnuje sposób trywialny, być może akurat będzie w sam raz:

*** i2cdriver.c ***

#include "i2cconfiguration.h"
#include "../lib/i2c/i2ccore.c"
#include "../lib/i2c/i2chardware.c"

*** i2cdriver.h ***

#include "i2cconfiguration.h"
#include "../lib/i2c/i2cinterface.h"

Plik i2cconfiguration.h jest częscią konkretnego projektu, podobnie jak
i2cdriver.c.

I tyle. W i2cconfiguratiion stado #define per projekt. W plikach lib/i2c
(h i c) od groma #ifdef na kaĹźdy wariant.

Powinno być najmniej intruzywne i najłatwiejsze w utrzymaniu przez
programistę C. Żadnych zmian w bibliotece. Wada: kompilujesz wszystko za
pierwszym razem. ALE. Dzieki make potem kompilujesz tylko zmiany, więc
narzut jest jednorazowy.


Re: [OT] Zarządzanie konfiguracją modułów ko du źródłowego

napisaC5%82(a):

Quoted text here. Click to load it

Quoted text here. Click to load it

Quoted text here. Click to load it

Ale to mi w C5%BCaden sposC3%B3b nie dotyka mojego problemu. JeC5%9Bl=
i odwoC5%82am siC4%99 w  =

"../lib/i2c/i2ccore.c" do nowego parametru konfiguracyjnego C_I2C_SHMOO,=
  =

to muszC4%99 go rC4%99cznie zdefiniowaC4%87 w kaC5%BCdym i2cconfigur=
ation.h w kaC5%BCdym  =

projekcie. JeC5%9Bli zmieniC4%99 nazwC4%99 i trochC4%99 funkcje para=
metru C_I2C_FOO na  =

C_I2C_BAR, to znowu zmiana w kaC5%BCdym projekcie. Chodzi mi o sposC3%B3=
b lub  =

narzC4%99dzie do automatyzacji takich zmian: wykrywanie niedodanych def=
inicji,  =

eliminacjC4%99 przestarzaC5%82ych definicji, itp.

Samo definiowanie konfiguracji per-projekt i jej #include w plikach  =

biblioteki to mam rozwiC4%85zane w miarC4%99 elegancko. Boli mnie tylk=
o potrzeba  =

rC4%99cznego czyszczenia konfiguracji per-projekt w wypadku zmian w opc=
jach  =

oferowanych przez bibliotekC4%99.

ae

Re: [OT] Zarządzanie konfiguracją modułó w kodu źródłowego
Quoted text here. Click to load it

#include "../lib/i2c/defaultconfiguration.h"
#include "i2cconfiguration.h"

To powinno zadzialać jak gdyby dziedziczenie parametrów. Możesz też uzyć
#ifndef FOO, #define FOO DEFAULR_FOO.

Ewentualnie, znacznie bezpieczniej, #ifndef FOO, #error "FOO not set"

Quoted text here. Click to load it

Najlepiej, gdybys tego nie robił w ogóle. takie narzędzie jest
niebezpieczne. Wydaje mi się, że najbezpieczniej jest zdać się na
kompilator. Czyli raz na jakiś czas budujesz wszystkie swoje żywe
projekty w całości i poprawiasz tam gdzie padła kompilacja.

Podobnie do tego pomysłu działa konfigurator opcji kompilacji linuxa
(kernela). Możesz sobie wyobrazić że tak jest ich dużo i że pojawia się
niedostrzegana wcześniej warstwa - zależności. W dodatku są ustalane
ręcznie. Np. sterownik do foobar można kompilowac tylko wtedy gdy jest
scsi itp. Takie zalezności są cieżkie w utrzymaniu bo nie wynikają
wprost z kodu tylko z jakieś metawiedzy poza.

Quoted text here. Click to load it

Tego nie unikniesz w przypadku ogĂłlnym. Jesli i2cdriver_init przyjmie 2
parametry a nie jeden to i tak musisz zmienić *wszystkie* projekty.
Wielu programistów C wpada tutaj na genialny pomysł uzycia makr albo
domyslnych parametrów, ale do ślepa uliczka. Tak czy inaczej refaktoring
bibliteki generuje zmiany po stronie klientĂłw.

Jesli masz klienta martwego, ale mimo to chcesz utrzymać kompilację, to
czasami wystarczy kod forkować, czyli #include
"../lib/i2c/v2/i2ccode.c". Nie jest to eleganckie, ale w przypadku
embedded pozwala projekt zamrozić. Problemem jest backportowanie poprawek.

Ten sposob jest uzywany też na linuxie, wystarczy zobaczyć katalog /lib
żeby zauważyć wiele róznych wersji bibliotek. Głównie dla supportu
starych klientĂłw.

Re: [OT] Zarządzanie konfiguracją modułów ko du źródłowego

napisaC5%82(a):

Quoted text here. Click to load it

Mam to doC5%9BC4%87 podobnie zrobione. Samo dziedziczenie defaultu to =
nie jest  =

najlepszy pomysC5%82, bo nowo dodany parametr moC5%BCe przejC5%9BC4%87=
 niezauwaC5%BCony. WiC4%99c  =

albo dziedziczC4%99 caC5%82C4%85 konfiguracjC4%99 moduC5%82u, albo =
wszystkie parametry muszC4%85  =

byC4%87 w projekcie przedefiniowane.

Quoted text here. Click to load it

To juC5%BC w zasadzie mam wbudowane: zawsze kompilujC4%99 z -Wundef i =
zamiast  =

#ifdef do wC5%82C4%85czania opcji uC5%BCywam "#if C_FOOBAR 3D%3D ENA=
BLED". Mam wtedy  =

warning gdy coC5%9B nie jest ustawione.

Quoted text here. Click to load it
B3%b lub
Quoted text here. Click to load it

Quoted text here. Click to load it
87% siC4%99 na  =

Quoted text here. Click to load it

Quoted text here. Click to load it

SkC5%82aniam siC4%99 ku uC5%BCyciu narzC4%99dzia, C5%BCeby zamiast =
otwieraC4%87 20 plikC3%B3w (a za  =

parC4%99 lat moC5%BCe 100?) i wszC4%99dzie robiC4%87 'paste' nowego =
parametru, mC3%B3c kliknC4%85C4%87  =

"update". OczywiC5%9Bcie kompilacja potem i tak jest nieodzowna (nie mC3%
B3%wiC4%85c o  =

teC5%9Bcie).

Quoted text here. Click to load it

Quoted text here. Click to load it

Nawet zaglC4%85daC5%82em mu w C5%BArC3%B3dC5%82a, czy by siC4%99 n=
ie daC5%82o czegoC5%9B wykorzystaC4%87, ale  =

trochC4%99 mnie odrzuciC5%82o. Poza tym w menuconfig jednak niezbyt do=
brze widaC4%87  =

nowe parametry, a usuniC4%99te po prostu po cichu znikajC4%85 (jeC5%9B=
li siC4%99 nic nie  =

zmieniC5%82o od ostatniego razu, jak kompilowaC5%82em kernel).

MiaC5%82em po prostu nadziejC4%99, C5%BCe kogoC5%9B juC5%BC to uwie=
raC5%82o i jakieC5%9B narzC4%99dzie  =

istnieje. No nic, napiszC4%99 sobie sam.

ae

Re: [OT] Zarządzanie konfiguracją modułó w kodu źródłowego
W dniu 06.05.2012 16:10, Andrzej Ekiert pisze:

Quoted text here. Click to load it

Przy okazji tematu nasuwa się pytanie: "Jak długo należy utrzymywać
stare projekty w stanie zaktualizowanym"   Czy po prostu nie umrą one
śmiercią naturalną i zatrzymają się na jakimś etapie ich rozwoju, a
łatwiej będzie stworzyć nowy projekt, na nowy procesor, w/g nowych
bibliotek, itp....

--
Jado




Re: [OT] Zarządzanie konfiguracją modułó w kodu źródłowego
Quoted text here. Click to load it

Jesli to stare projekty to po prostu zamraĹźasz implementacje bibliotek i
ich nie rozwijasz. Ile rĂłwnolegle utrzymujesz Ĺźywych projektĂłw? Kilka?

Zamrozić biblitekę można też pisząc adapter do nowszej wersji. Niestety
to generuje czasem spory kod i potrafi też szlag trafić.

Ostatecznie po prostu porzucaj kod starych projektĂłw poprzez usuwanie go
z repozytorium. Zawsze się możesz wycofać jak-by-co. W embedded to
jak-by-co nie występuje za czesto.

Quoted text here. Click to load it

Zerknij jeszcze na konfigurator eCos.

IMHO zamieniasz siekierkę na kijek. Now narzedzie nie usunie problemów
starego. Dlaje będziesz walczył z poprawianiem kodu, z zastanawianiem
się jaki podać parametr w miejsce dwoch poprzednich itp. Zawsze będzie
ywmagana ingerencja w kod. Tak czy inaczej.

Site Timeline