Jaki jest najlepszy sposób udostępniania plików źródłowych Delphi wśród projektów?

Question

Jaki jest najlepszy sposób udostępniania plików źródłowych Delphi wśród projektów?

Wyjaśnienie: Chcemy użyć pojedynczego pliku źródłowego w wielu projektach Delphi. Używamy naszego narzędzia SCM do umieszczania tego samego pliku w wielu folderach, ale nie jest to super-eleganckie doświadczenie i rozważamy także migrację do narzędzia, które tego nie obsługuje.

Jak już bada tę kwestię, ja już za kilka różnych podejść, ale chciałbym wiedzieć, co robisz i jak znaleźć swoje podejście.

Ważne scenariusze:

• Kod czasu
  • Dodanie nowego zależność udostępniania powinny wymagać wyraźnej deklaracji, tak, że dzielenie się udało.
  • Dodanie nowej zależności współdzielenia powinno być nadal stosunkowo proste; nie powinno wymagać skomplikowanego procesu.
    • Jeden plik zawierający listę wszystkich "zaimportowanych" plików projektu (z zewnątrz) byłby niezły.
• kompilacji
  • Wszystkie projekty powinny zawsze zbudować z jednej aktualnej wersji (obecnej jako stanu synchronizacji źródło powiększonej lokalnych edycji).
    • (Utrzymanie różne wersje w różnych miejscach należy użyć pliku rozgałęzień, co nie jest tematem, tutaj.)
  • czy każdy projekt powinien być w stanie wpłynąć na kompilację pliku udostępnionego za pomocą różnych ustawień kompilatora (w tym flagi) jest dyskusyjna.
    • Jest to prawdopodobnie łatwiejszy w utrzymaniu (tj. Długoterminowy) kod źródłowy, który jest zawsze budowany konsekwentnie.
    • Łatwiej jest wprowadzić poprawki serwisowe (np. Krótkoterminowe), jeśli zakres wspomnianych zmian można łatwo ograniczyć do jednego projektu.
• Debug czasie
  • Poprawna wersja źródła powinien automatycznie otwarte, gdy wchodząc do rutynowego lub ustawienie punktu przerwania.
  • Edycja wyświetlanego źródła powinna wpłynąć na kolejną kompilację.
    • Nie chcemy debugować przeciwko tymczasowej kopii źródła: w zamieszaniu pewnie stracilibyśmy kod.

Uwagi:

• Near-Term:
  • Co będzie najprostsze podejście do umieszczenia w miejscu?
• długoterminowa:
  • Jakie podejście będzie najprostszy w obsłudze i konserwacji?

Dzięki z góry za opinie!

Mattias

---

--- UPDATE ---

Dzięki za opinię, poprzez odpowiedzi, komentarze i głosy!

Rozpocząłem drogę do umieszczania współdzielonych plików w jednym projekcie "producenta" i importowania listy skompilowanych plików do każdego projektu "konsumenta". Projekty są łączone razem z MSBuild. Gdy wszystko będzie lepiej zrozumiane, zmienię to pytanie i odpowiedź "Projekt biblioteczny", by podzielić się tym, czego się nauczyłem.

Bądź na bieżąco! (Ale nie wstrzymywać oddechu, będziesz asphyxiate ciągu kilku minut: P)

Answer 1

Zastosowanie źródłowy systemu sterowania funkcją Udostępnianie plików

• Pro: Szybka i łatwa w konfiguracji, jeśli SCM system to obsługuje.
• Pro/Con: Każdy projekt konsumencki może niezależnie wpływać na czas kompilacji.
• Con: Nie ma oficjalnej lokalizacji w lokalnej kopii roboczej źródeł.
  • Może to prowadzić do zamieszania.
• Konw .: Zmiany źródła nie są odzwierciedlane w innych lokalizacjach do momentu sprawdzenia i ponownego pobrania.
  • Aby poprawnie zweryfikować inne projekty, przed meldowanie się możliwe, ale królewski ból w tyłek.
• Con: Nie wszystkie systemy SCM obsługują wspólne pliki.
  • Najbliższą funkcją Subversion jest folder svn: externals.

(Edycja: zmieniono tytuł to aby uniknąć nieporozumień.Oczywiście, każdy powinien użyć Kontrola źródła! :-))

Answer 2

Kopiuj na kompilacji

• Pro: Udostępnianie plików można zarządzać plik po pliku.
• Pro/Con: Każdy projekt konsumencki może niezależnie wpływać na czas kompilacji.
• Con: Debugger połączy się z tymczasową kopią, a nie z oficjalną wersją.
  • TODO: Sprawdź, czy jest jakiś sposób, aby to zmienić.
• Con: Może trochę pracy, aby skonfigurować projekty MSBuild.
• Con: Może być trudny do przyrostowego budowania udostępnionych plików.
  • Może wymagać przepisania niektórych zasad MSB Delphi.

Answer 3

Copy-kompilacji Usuń

• Pro: tylko jeden oficjalny kopię każdego pliku do edycji.
• Pro: Debugger nie połączy się z kopią tymczasową, ponieważ została usunięta przez czas debugowania.
  • TODO: Sprawdź, czy debugger znajdzie oryginalne źródło, jeśli umieścimy je w "Ścieżce przeglądania".
• Pro: Udostępnianie plików może być zarządzane plik po pliku.
• Pro/Con: Każdy projekt konsumencki może niezależnie wpływać na czas kompilacji.
• Con: Może trochę pracy, aby skonfigurować projekty MSBuild.
• Con: Może być trudne/niemożliwe do przyrostowego budowania udostępnionych plików.
  • Może wymagać przepisania niektórych zasad MSB Delphi.

Answer 4

użyć biblioteki projektu

• Pro: Tylko kiedykolwiek jedna kopia każdego pliku do potencjalnie edycji.
• Pro: Tylko jedna kompilacja dla każdego pliku źródłowego.
  • Mniej czasu na kompilację.
  • Konsekwentna kompilacja wśród zależnych projektów.
  • Naturalne przyrostowe kompilacje.
• Pro: Debugger w naturalny sposób łączy się z odpowiednim źródłem.
  • TODO: Potwierdź.
• Pro/Con: Projekty konsumenckie nie mogą niezależnie wpływać na czas kompilacji.
• Con: Może być trudno zarządzać udostępnianiem na poziomie pliku po pliku.
  • TODO: Zbadaj.
• Con: Potrzeba dużego wysiłku, aby skonfigurować.
  • Tworzenie projektów MSBuild.
  • Wymagane ustawienia projektu muszą być scentralizowane, a zmiany te muszą zostać zweryfikowane.

Answer 5

Myślę, że nie są wymagane żadne specjalne rozwiązania. W naszym projekcie (kilka aplikacji, które dzielą duże obszary kodu), stosujemy następujące podejście:

1. Podział kodu źródłowego na foldery.
2. Tworzenie pakietów dla jednostek logicznych wspólnego kodu.
3. Monolit obsługujący (bez użycia pakietów) i kompilacje partowane.
4. Monolithy są używane do kodowania i debugowania. Każda aplikacja ma swój własny katalog wyjściowy jednostek, więc wszystkie z nich są budowane niezależnie.
5. Ograniczenia zależności są wymuszane przez ścieżki wyszukiwania projektów.
6. Parted build są tworzone automatycznie (korzystamy z serwera CruiseControl i projektu MSBuild). Automatyczna kompilacja usuwa wszystkie foldery tymczasowe przed kompilacją, więc nie ma zależności między kolejnymi kompilacjami.

W naszym przypadku nie mogliśmy kontrolować listy zaimportowanych plików. Możemy jednak kontrolować listę zaimportowanych pakietów w kompilacjach z partiami. Mniejsze pakiety oznaczają lepszą ziarnistość. Jeśli ktoś dodaje zależność do jednostki, znajduje się w folderze, który nie jest dostępny w ścieżce wyszukiwania, a pakiet zawierający tę jednostkę nie znajduje się na liście zastosowań, to kompilacja parted nie powiodła się. Tak więc, aby dodać zależność, wymagana jest jawna akcja (modyfikująca skrypt MSBuild generujący pliki CFG dla kompilacji partowanej).

P.S. Używamy pakietów, aby nie kontrolować zależności, ale z powodu wersji systemu Windows, która nie jest NT, występują problemy z uruchomieniem dużych aplikacji. Kontrola zależności jest więc efektem ubocznym. Parted builds są uważane za "release", a monolith - za konfigurację "debugowania". Aplikacje Monolith są używane tylko do kodowania i debugowania. Programiści pracują z aplikacjami monolitowymi i wprowadzają własne zmiany w konfiguracjach projektów, takich jak dołączanie informacji diagnostycznych VCL, błędy włączania i wyłączania zakresu, optymalizacja itp. Jednak po zatwierdzeniu do SVN, CC próbuje utworzyć kompilację. Ignoruje pliki CFG z repozytorium i tworzy je ponownie za pomocą specjalnego zadania projektu MSBuild. Dzięki temu możemy być pewni, że nie pojawiły się żadne problemy z zależnościami (i przeprowadzić również inne kontrole).

O ile nie potrzebujemy monolitów i rozczłonkowanych kompilacji jednocześnie, mamy tylko jeden projekt na aplikację. Jeśli chcesz zbudować obie wersje w skrypcie MSBuild, możesz po prostu dodać jeszcze jeden cel, ponownie utworzyć CFG jeszcze raz i określić jeszcze jeden katalog wyjściowy Jednostki. Oczywiście, jeśli obie wersje są wymagane dla programistów, wygodniej byłoby mieć więcej projektów.

Answer 6

Nie jestem pewien, czy zrozumiałem pytanie poprawnie. W każdym razie, gdy buduje pakiet aplikacji (kilka projektów, ale wiele wspólnego kodu), tworzymy strukturę folderów tak:

\Main 
    \Project1 
    \Project2 
    ... 
    \CommonUnits 

Dodajmy wspólnych jednostek do odpowiednich projektów (bez względu na to nie jest w tym samym folderze co plik projektu). Co więcej, czasami łatwiej jest stosować definicje warunkowe na poziomie projektu (Project | Options | Directories/Conditionals) dla małych różnic w kodzie. Na przykład, Project1 będzie mieć zdefiniowane coś takiego jak "APP_PROJECT1", a następnie możesz użyć $ IFDEF w popularnych jednostkach do napisania określonego kodu.

Co ważne: w tym przypadku lepiej jest mieć repozytorium kontroli źródło całego pakietu (root \ main, oczywiście).