W dniu 06.05.2012 13:09, Andrzej Ekiert pisze:

> Problem:
> W każdym projekcie, który korzysta z danego modułu, ustawiamy
> odpowiednio wszystkie parametry. Następnie, z dowolnej przyczyny, w
> bibliotece zmieniamy zestaw parametrów konfiguracyjnych oferowanych
> przez moduł. W efekcie musimy poprawić pliki konfiguracyjne w każdym z
> projektów, co przy rosnącej liczbie tych projektów po chwili staje się
> boleśnie pracochłonne.

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.

> Szukam mądrej metody radzenia sobie z tą niepotrzebną pracą. Metody
> aplikowalnej do kodu w C i assemblerze (choć bardzo chętnie usłyszę,
> jeśli w C++ da się to zrobić jakoś lepiej). Ważne, aby metoda nie
> powodowała skutków run-time (np. zamiast ustalać rozmiar pamięci w
> konfiguracji, mogę mieć zmienną ustawianą w funkcji inicjalizującej, do
> pinów mogę mieć callbacki włącz/wyłącz,

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

> sprzętowego modułu I2C mogę mieć dodatkową warstwę abstrakcji, ale
> wszystko to kosztuje pamięć lub cykle, a w przypadku niektórych
> parametrów jest praktycznie niewykonalne - poza tym tylko to przesuwa
> problem ze zmian konfiguracji, na zmianę API).

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.