[Linux][Qt][C++] Współpracownik przy prostym projekcie Open Source

Hejka,
Naszła mnie ostatnio ochota na napisanie apki w Qt do zarządzania ręcznie skompilowanymi bibliotekami w wielu wersjach. Ewentualnie można to rozdzielić na 2 programy w stylu libmanager-cli i libmanager-qt.

Wstępnie ma to działać mniej więcej tak (uwzględniam możliwość zmian):
- Po wybraniu przez użytkownika katalogu z podfolderami 'include', 'lib' i plikiem 'metadata' program kopiowałby na podstawie pliku z metadanymi wszystko odpowiednio do folderu ;
- Pozwalałaby przeglądać listę bibliotek i pozwalać na wybór, która ma być symlinkowana do  i ;
- Możliwość zmiany domyślnych ścieżek (, , );
- Usuwanie wybranych wersji lub całych bibliotek;
- Prosty kreator pliku metadata;
- Obsługa z poziomu terminala.

Plik metadata (w formacie xml albo json, to się zobaczy) zawierałby:
- Nazwę biblioteki;
- Dokładną wersję;
- Informację o symbolach debugowania;
- Datę kompilacji.

Jeśli ktoś jest chętny tutaj jest mój e-mail: koczurekk@gmail.com
W razie pytań dot. projektu proszę pisać tutaj, żeby wszyscy mogli to potem zobaczyć.

Pozdro

Jaki jest cel tego projektu? :) Bo w zasadzie posiadanie n-wersji tej samej biblioteki jest bezsensowne. W praktyce zawsze chcesz używać najnowszej biblioteki, a ewentualne stare projekty należy zaktualizować do nowszej wersji bibliotek. N-wersji tej samej biblioteki oznacza posiadanie n-wersji plików nagłówkowych, libów i symboli debugowych. Przykładowo: posiadam 28 skonfigurowanych bibliotek. Same źródła tych bibliotek zajmują 100MB. Biblioteki w debug zajmują 220MB. Biblioteki w Release zajmują 490MB. Innymi słowy: 28 bibliotek zajmuje 810MB - bez wersjonowania, które Ty proponujesz.

Stosując wersjonowanie bardzo szybko będziesz miał problemy z miejscem na dysku, a ponadto będziesz musiał utrzymywać n-projektów i każdy z projektów będzie używał innych źródeł. Co więcej: bugi będziesz musiał naprawiać w każdej wersji posiadanych bibliotek i tym samym wszystkie wersje będziesz musiał przekompilować po to aby naprawić buga we wszystkich bibliotekach. To będzie kosztowne czasowo, a wszystko przecież chodzi o oszczędność czasu no nie?

Głównie do szukania bugów pojawiających się z zaskoczenia po aktualizacji, utrzymanie choćby 4 wersji (dajmy na to 1.0, 1.0-debug, 1.2, 1.2-debug) to mordęga, sprzątanie po tym też. Drugim zastosowaniem jest możliwość wygodnego ogarniania 2 projektów używających 2 wersji tej samej biblioteki, gdzie poprawa kodu jednego z nich jest zbyt kosztowna w stosunku do korzyści. Więc oczywiście nie chodzi o trzymanie N wersji, co oczywiście nie ma sensu. No i eliminuje to jeden przykry dylemat przy kodzeniu na Linuksie - zainstalować bibliotekę z repo i ryzykować nieoczekiwaną aktualizację, która może coś popsuć albo ręcznie skompilować i zainstalować "make install", ale pogodzić się z brakiem kontroli nad plikami na dysku.

Jeżeli się nie mylę to Twój meta data to w praktyce to samo co makefile. Makefile są dostarczane razem ze źródłami projektów więc w praktyce wystarczy wpisać polecenie 'make' pod linuxem.

Nie bardzo, moje metadata ma jedynie zawierać informacje o gotowej binarce, makefile to zbiór reguł budowania a 'make' zwykle kompiluje projekt.

No i eliminuje to jeden przykry dylemat przy kodzeniu na Linuksie - zainstalować bibliotekę z repo i ryzykować nieoczekiwaną aktualizację, która może coś popsuć albo ręcznie skompilować i zainstalować "make install", ale pogodzić się z brakiem kontroli nad plikami na dysku.

Nie wystarczy podać --prefix do configure lub analogicznej opcji dla innych niż autohell systemów budowania? Albo zbudować normalną paczkę, którą się zajmie menadżer paczek (w Archu trywialne, w Debianie i pochodnych proste, z innymi distro nie miałem styczności)?

Gorzej w takim układzie:

System paczek (w każdym razie debianowy) w takich sytuacjach pluje błędami przy instalacji a nawet jeśli się uda, wszystko się sypie po usunięciu libexample w wersji 1.1.0.