Temat: Duży projekt - wolna kompilacja

Ok! Przekonałeś mnie :) Muszę to sprawdzić :) Dzięki ;)

Temat: Duży projekt - wolna kompilacja

Piotr L.:
Podział na DLL-ki to osobna sprawa.

Masz tak:
Moduł A (ModulA.pas) : implementuje interfejs I1 oraz używa modułu który go definiuje - ModulAIntf.pas
Moduł B (ModulB.pas): używa obiektów typu I1 oraz używa modułu ModulAIntf.pas

Gdy zmieniasz ModulAIntf.pas musisz przekompilować wszystkie moduły (unity i DLLe) go używające.
Gdy zmieniasz tylko ModulA.pas musisz przekompilować tylko ModulA.pas ( i DLL go zawierający)

Czy interfejsem jest unit zawierający obiekty typu "interface" czy funkcje eksportowane z DLL-ki to rzecz raczej drugorzędna, przy czym oczywiście "interface" jest obiektowy a DLL-ka nie.

Czyli podsumowując, możesz to zrobić w oparciu o obiekty typu "interface" lub unity eksportujące dla BPL / DLL.

Tyle teoria. Jak jest praktycznie - do przetestowania.

W praktyce jest tak samo, a do OP - już miałem napisać, że nie masz pojęcia jak działają interfejsy, ale... uczysz się ;-)

Jeszcze coś dodatkowo:
pliki *Intf.pas ograniczają wpływ zmian na pozostałe moduły (gdy zmieniasz części prywatne / protected to nie musisz przekompilowywać modułów klienckich).

Gdy masz normalne klasy z częścią private / protected, to mimo że nie udostępniasz tych elementów na zewnątrz, zmiana tej części powoduje, że struktura obiektu / klasy się zmienia i trzeba przekompilować resztę.
Na szczęście kompilator sam to wyłapuje.

Macie racje i w ogóle, ale zapominacie op jednym ; Delphi to nie C++ i kompilacja w Delphi jest bardzo szybka.
Dlatego pytam - chodzi o kompilację (Compile Ctrl+F9) czy o Build (Shift+F9).

Dwa - jeśli ten projekt używa DLL, a w te DLL to takie niby-quasi-moduły w których jest wszystko to co w normalnej aplikacji (okna, komponenty wizualne, spora część VCLa itd.) to to o pupę rozbić!
po pierwsze, bo to źle działa. Dużo o tym było, można sobie poszukać w sieci...
Po drugie - z definicji kompilacja takiego DLL w Delphi działa tak, że WSZYSTKO co ów DLL wymaga do życia jest do niego dołączone statycznie. Ergo - każdy unit który jest użyty w danym DLL jest do niego wkompilowany.
Każdy unit w każdą DLLkę - no i masz odpowiedź dlaczego to kompiluje się wolno.
A więc skoro masz 20 DLL w których jest np. użycie TForm, to w każdym DLL znajdzie się kopia Forms.pas - itd.

Rozwiązaniem jest np. podział aplikacji na moduły tak jak opisał to Piotr, ale moim zdaniem to armata na muchę - w Waszym zastosowaniu...
Proponuję Wam dwa wyjścia - zrezygnujcie z DLL na rzecz jednego EXE; sam napisałeś że zależności pomiędzy DLLami jest tak wiele, że owa modularność jest iluzoryczna i nic tak naprawdę nie daje.
Kompilacja jednego EXE będzie tak pewnie za 20x szybsza niż wszystkiego; choćby dlatego, że linker nie musi się męczyć, a op drugie Delphi ma fajny przyrostowy kompilator który działa bardzo szybko.

Inne rozwiązanie - BPL.
Nie używajcie DLL tylko BPL; ma to swoje wady, ale w Waszym przypadku ma tylko i wyłącznie zalety, bo:
1) Macie zamrożone środowisko, czyli piszecie wszystko w jednej wersji z wykorzystaniem konkretnych wersji bibliotek.
2) Jest dużo prościej niż w przypadku DLL - nie muszisz niczego eksportować z DLL'a - po prostu robisz uses modułu z innego BPL i go używasz tak jak by to było jedno exe. A IDE samo doda do sekcji required odpowiedniego BPLa. Wszystko.
3) Jest szybciej i zdecydowanie bezpieczniej, bo to nie jest n managerów pamięci tylko jeden - zarządzanie pamięcią i przekazywanie obiektów () pomiędzy DLL-Host-DLL zawsze było kłopotliwe, tylko tak naprawdę mało programistów Delphi zdaje sobie z tego sprawę.
4) Kompilacja - jest błyskawiczna, dlatego, że jest kompilowany tylko kod z BPLa. Nic nie jest statycznie linkowane do BPL, wszystko jest dynamiczne.
5) Migracja z DLL do BPL będzie prawie bezbolesna, tyle że to wymaga "otrzaskania" się z pewnymi ograniczeniami i wymaganiami BPLi jako takich.

Założę się, że czas budowania (Build) waszego projektu po przejściu na BPL będzie wielokrotnie krótszy niż obecny czas kompilacji (Compile).
A czas kompilacji będzie pomijalny...

PS.
Możesz mi wierzyć co piszę, tworzyłem i zarządzałem projektem, który składał się z ok,. 120 BPLi; teraz mam projekt podobnej wielkości, ale składa się z ok. 50 BPLi.
Nie wiem ile było linii kodu, bo to mało istotne z mojego punktu widzenia, może dlatego że nie tworze okien tak jak to się w Delphi robi, tylko całe okno tworzone jest dynamicznie na podstawie metadanych - po prostu nienawidzę wizualnego układania komponentów na formatkach, brrr...

Temat: Duży projekt - wolna kompilacja

Polecam na początek bardzo proste rozwiązanie http://www.cnpack.org/index.php?lang=en z opcją "Uses cleaner".

Przynajmniej u mnie, w projekcie, w którym to się sprawdziło, były w uses na każdym kroku całe masy odwołań zupełnie zbędnych, czy to dodanych na zasadzie "będzie potrzebne przy klepaniu właściwego kodu", albo po prostu takich, które przez lata zmian i poprawek się zwyczajnie zdezaktualizowały. Czas pełnego buildu udało się skrócić o jakieś 80% i był to już akceptowalny poziom 20 sekund :-)

Tak czy siak, jest to też dobra okazja do tego aby nauczyć się pisać kod bez robienia co chwilę compile/build. ;-)

Temat: Duży projekt - wolna kompilacja

Nie klikam compile/build co chwilę :D
Ta opcja z CnPack nie wiele daje...

Ale okazało się że opcja skonwertowanie wszystkich dfm-ów na text trochę pomogła, przynajmniej w kwestii wywalania się Delphi i dziwnych błędów.
Reszta operacji to było dzierganie plik po pliku, szukanie zależności.
Zeszliśmy z 1:20 do 10s. :) Jest nieźle ;)Ten post został edytowany przez Autora dnia 17.07.14 o godzinie 22:24