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:
> Przedstawię najpierw scenariusz oraz problem:
>
> Mamy bibliotekę modułów kodu źródłowego, które są używane w wielu
> projektach. Każdy z modułów ma swoje parametry konfiguracyjne, którymi
> można go "dostroić" dla potrzeb konkretnej aplikacji i płytki - np.
> moduł będący driverem do scalaka radiowego ma m.in. parametry
> określające do jakich pinów procesora scalak jest podpięty, moduł będący
> driverem do pamięci na I2C ma parametry mówiące którym interfejsem I2C
> mikrokontrolera należy z tą pamięcią rozmawiać, jaki jest rozmiar
> pamięci i który pin procesora to CS, itp.
>
> 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.
>
> 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, też ustawiane przez API, a do
> 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).
>
> Jestem blisko rozpoczęcia pisania programu, który będzie mi zarządzał tą
> konfiguracją, tzn. za jednym klikiem porówna konfiguracje wszystkich
> zarządzanych projektów, pokaże gdzie są nieustawione parametry, gdzie są
> ustawione już nieistniejące parametry, gdzie wartość parametrów różni
> się od domyślnej, a następnie umożliwi wybranie akcji, ustawienie
> właściwych wartości i uaktualni zarządzane pliki konfiguracyjne. Ale
> trochę mam nadzieję, że istnieje jakiś inteligentny sposób, na który nie
> wpadłem.
>
> ae