Câteva cuvinte despre proiect, pentru cei care au uitat. Lazy Delphi Builder a fost conceput ca un instrument pentru simplificarea asamblării proiectelor / componentelor. Va scana folderele, va găsi toate fișierele necesare acolo. Sugerează să alegeți ce să colectați și ce nu. Permite specificarea parametrilor ansamblului și a dosarelor în care să se pună fișierele primite. Va colecta totul așa cum ar trebui și chiar va copia toate fișierele de resurse într-un singur folder. Și, de asemenea, salvați toate fișierele selectate cu setările de pe disc și veți putea să o porniți mai târziu. Poate înlocui unele dintre căile cu variabile. Stochează setările într-un fișier text.
Saptamana trecuta lucram pe proiect in fiecare zi cateva ore pe zi. A lins lucrarea versiunii de consolă și a făcut modul de compilare rapidă. În final, am făcut posibilă înlocuirea valorilor variabilelor de mediu din linia de comandă. N-am avut timp să lucrez la instrucțiuni.
Lucrați foarte mult pe proiect. Și, în primul rând, să lucrăm la simplificarea programului. Pe de o parte, Lazy Delphi Builder vă permite să colectați toate fișierele (și dcu, și chiar resursele) în folderele specificate. Și, pe de altă parte, aproape nici unul dintre programatorii pe care i-am intervievat consideră acest lucru ca fiind nevoie. =) Și cei care văd preferând să cheme dcc32.exe cu parametrii necesari și LazyDB pentru a le face ceva. Trebuie să simplificăm cumva programul de lucru, deoarece sa dovedit a fi complicat. La urma urmei, chiar și cu o mașină de spălat Samsung este mai ușor de înțeles decât cu asta.
Istoria schimbărilor
- simplificarea muncii cu programul
- mimicry în conformitate cu comportamentul implicit Delphi la instalarea componentelor (lăsați dcu în directorul sursă sau în folderul implicit Dcu afară și sugerați adăugarea acestor foldere în calea căutării librăriei). Deși ... poate că nu o voi face.
- lucrați la documentație.
"lăsați dcu în directorul sursă sau în folderul implicit Dcu out"
Mi se pare că nu este necesar să se stocheze codurile sursă și codurile sursă într-un singur dosar.
De mulți ani de lucru cu Delphi a dezvoltat următoarea regulă pentru structura fișierelor:
\ Packages, \ Sources, \ Help.
\ Lib. În Lib doar DCU / BPL sunt stocate, mediul nu are acces la Surse (căile sunt înregistrate numai în Lib). În cazul proiectelor mari, o astfel de schemă economisește foarte mult timpul de compilare.
Cu toate acestea, aceasta este doar IMHO.
Excelent IMHO. De asemenea, cred că locul ar trebui stabilit.
La mine toate fișierele dcu sunt stocate într-un dosar separat. Mai precis, am un dosar comun pentru toate dcu-shek.
Mai exact, chiar și pentru mine pentru fiecare versiune de Delphi există un folder comun Build și în subfoldere: Bin, Dcp, Bpl, Dcu, DebugDCU și Res.
Am scris aici despre ce ierarhie de dosare prefer să folosesc.
Toate aceste dosare sunt incluse în calea Bibliotecii. În principiu, numai ele sunt incluse.
Inițial, Lazy Delphi Builder a fost închis pentru o astfel de organizație la locul de muncă.
Dar. majoritatea programatorilor pe care i-am intervievat nu se deranjează prea mult cu configurația locului de muncă, lăsând setările implicite. În mod implicit, în Delphi nu există un folder dedicat separat pentru fișierele utilizatorului Dcu. Seturi diferite de componente oferă folderele Lib \ VersionDelphi și Lib \ VersionDelphi \ Debug. Nu văd o varianta ideală încă.
Acum, pentru a lucra cu utilizatorul LazyDB trebuie să specificați cel puțin un folder fișier DCU. Și mulți utilizatori întreabă adesea ce să intre și de ce. a venit Prin urmare, ideea de a permite nimic să indice și să lase fișierele DCU care au (deoarece LazyDB ignoră .CFG fișiere, și mai recent, setări opționale și ignoră .dof. Bdsproj. Dproj).
În general, nu am încă o viziune despre cum să o fac mai ușor și mai convenabil.
"Și, în mod implicit, în Delphi nu există un folder dedicat separat pentru fișierele utilizatorilor Dcu"
Hmm. În Delphi 7 Projects \ BPL. În rest - nu-mi amintesc, încă stau pe D7.
"Diferitele seturi de componente oferă folderele Lib \ VersionDelphi și Lib \ VersionDelphi \ Debug"
Din păcate, da. Prin urmare, petrec o perioadă infinită de timp instalând pachete pentru a le aduce în structura "mea", ceea ce provoacă râsete și neînțelegeri ale altora :)
Mi se pare că "opțiunea ideală" este ceea ce se face în LazyDB. Cel puțin, pentru mine. Cred că este suficient să documentăm acest lucru în detaliu și oamenii se vor obișnui cu asta. Ei bine, oricine nu se obisnuieste cu aceasta se poate adapta la gustul tau. Pentru toate programarea și livrarea de proiecte, eu sunt convins că vă poate pune în proiect / program de orice logică (exagerez un pic), dar în cazul în care este documentat faptul că 90% dintre utilizatori spun: „cum-ar putea fi altfel“
Apropo, primul meu post a fost distorsionat in timp ce ma mentin. Am vrut să spun "Pachet" \ Surse, "Pachet" \ LibNN, etc. De ce parantezele unghiulare au dispărut.
>> Și, în mod implicit, în Delphi nu există un folder dedicat separat pentru fișierele utilizatorului Dcu "
> Hmm. În Delphi 7 Projects \ BPL
Nu este vorba despre BPL-kah, ci despre fișiere DCU. Pentru aplicația BPL, există un dosar prestabilit. Dar pentru dosarele dcu acolo. Și cred că chiar înțeleg de ce. Atunci când o persoană are o grămadă de proiecte care conțin fișiere de nume Unit1, UNIT2, (și tocmai astfel de nume oferă implicit IDE, iar acestea sunt numele folosite în teanc demo-uri), compilarea fiecărui proiect care conține o unitate cu un nume folosit va suprascrie unitatea. În general, terciul va fi.
Apropo, există o astfel de capcană.
Am un proiect care, din anumite motive, este testat și colectat de diferite versiuni ale Delphi (5,6 și 7) în diferite sisteme de operare. Asamblarea se face prin nant și una dintre etapele în care este generarea unui fișier exe prin apelarea Lazy Delphi Builder cu un profil pre-creat.
Scriptul de nant este suspendat în sistemul de control al versiunii și totul este bine cu el, dar nu pot adăuga profilul Lazy Delphi Builder (LDB), deoarece dacă profilul nu specifică ce versiune de Delphi să colecteze, atunci (LDB) oprește automat procesul. Au aceleași mai multe profiluri pentru diferite versiuni de Delphi, care diferă numai într-o singură linie - destul de incomod și costisitoare, să nu mai vorbim de faptul că trebuie să se schimbe script-ul construi, setarea serverelor testirovochnyh pe care le rula corect construi țintă, etc.
Deoarece propunerea este aceasta: dacă profilul nu specifică versiunea Delphi și mașina are o singură versiune, atunci trebuie să încărcați setările și căile din ea și să încercați să asamblați proiectul.
Într-un ideal - să aibă un profil la nivel mondial, care va rămâne setările implicite, iar apoi setările setările globale profilului suprascriere din profilul curent, dacă setarea profilului curent este omis, acesta este eliminat din profilul global.
De asemenea, ideal ar fi un mecanism de aplicare, prin intermediul setărilor de directoare: de exemplu, directorul merge cu o anumită setare de profil care va suprascrie setarea pe un profil la nivel mondial și va fi utilizat pentru toate profilurile din acest director și subfoldere. Ie există un loc suplimentar în care pot fi făcute setările.
În ceea ce privește aceeași versiune de Delphi, utilizate în asamblarea, s-ar putea arata ca. depozit Clone în directorul C: \ Proiecte \ D6 și asamblare suplimentară ar duce la asamblarea prin intermediul Delphi 6, și o clonă a depozitului în C: \ Proiecte \ D7 - Delphi 7 (esstestvenno în ambele directoare sunt ascunse) fișiere (? conform instrucțiunilor)
> Pentru a avea mai multe profiluri pentru diferite versiuni ale dolphi, care diferă doar într-o singură linie - este destul de incomod și costisitor.
Utilizați același fișier de proiect (dpk sau dpr) pentru toate versiunile de Delphi?
Deoarece în cazul componentelor, toate bibliotecile conțin, de obicei, un fișier .dpk separat pentru fiecare versiune de Delphi, iar în aceste cazuri profilurile vor diferi mai mult de o singură linie. De asemenea, m-am gândit la acest caz, dar nu m-am gândit niciodată cum să o fac mai bine. Până acum văd doar 2 opțiuni:
1) Introduceți în LazyDB, variabile condiționale de mediu, schimbând valoarea în funcție de versiunea selectată a Delphi
2) Introduceți suportul pentru condițiile (a la) pentru grupurile de fișiere, inclusiv posibilitatea de a specifica ce fișiere vor fi utilizate pentru versiunea Delphi. În timp ce se aplecă spre el.
Ambele variante sunt încă destul de greu de implementat și de utilizat. De aceea, pentru astfel de cazuri este necesar să se utilizeze 2 profile separate.
Cu toate acestea, pentru cazul în care același proiect este compilat prin diferite versiuni, voi urma sugestia dvs., da. =)
> propoziția este următoarea: dacă profilul nu specifică versiunea Delphi și mașina are o singură versiune, atunci trebuie să încărcați setările și căile din ea și să încercați să asamblați proiectul.
Mă gândeam la ce versiune de Delphi să folosească linia de comandă. Ceva de genul: "/ D 7", "/ D 12", "/ D 15". Și adăugați parametrul "/ D Any", care permite utilizarea primei versiuni care a fost găsită. Dacă versiunea Delphi nu este specificată în profil nu este disponibilă, va fi utilizat modul "/ D Any".
Dar nu voi susține suprapunerea profilurilor cu priorități diferite. Deoarece pista mai târziu, setările pe care în cazul în care face este o chestiune de complexe și confuze. Ceva similar, cum ar fi deja puse în aplicare pentru dcc32 (Proekt.cfg și fișiere .dof), care, prin modul în care sunt ignorate atunci când construirea Lazy Delphi Builder-lea, tocmai pentru a fi siguri că totul se întâmplă cu aceleași setări.
Dar promit să mă gândesc la această idee.
De ce Nant -. Pentru că celălalt grup de dezvoltatori sale sunt deja utilizați, au deja o licență pentru NantBuilder, pe servere a fost instalat, și așa că, desigur, ca dezvoltator al lumii Linux, și Python ar folosi waf, dar se pare că este destul de dificil în continuare. dorința a fost eliminată din cauza paginii proaste și a lipsei de demonstrație a faptului că proiectul se dezvoltă în mod activ.
Comparația nu a fost, a fost doar opinia mea personală :) Da, și ce parametri pentru a compara - toate cele trei menționate de configurare XML cum ar fi despre aceeași, nici unul dintre utilitatea trei prezentate nu poate compila și instala componenta în Delphi IDE în mod automat, ci pentru că trebuie să alegeți utilitarul prin care puteți obține rapid ajutor.
În ceea ce privește al treilea punct - mă voi gândi la asta și voi scrie mai mult.