1. Dom
  2. Pytanie i odpowiedź
  3. Proces rozwoju

Proces rozwoju

2013-01-17 35 views
7

Jaki jest zalecany proces rozwoju programów D, które używają pakietów sklonowanych z github i budowanych osobno?Proces rozwoju

Zazwyczaj w stosunku do tego, jak C/C++ projekty są zbudowane przy użyciu sprawiają, autotools, cmake itp

Większość innych specyfikacji budować mieć cel instalacji. Czy w kompilacji powinien istnieć cel instalacji, czy powinniśmy po prostu połączyć bibliotekę bezpośrednio z miejscem, w którym zostanie umieszczona, gdy zostanie ona zbudowana, i dodać rejestr do swojej biblioteki w D_INCLUDE_PATH, a następnie bezpośrednio do nich, używając DFLAGS=-I<D_INCLUDE_PATH>?

Źródło

2013-01-17 Nordlöw

+1

+1 za pytanie. Jakiś czas temu też tego szukałem i nie mogłem nic znaleźć. Skończyłem używać CMake do własnych projektów i ręcznie instalowałem biblioteki do osobistych katalogów jak '~/droot' (więc biblioteki były w' ~/droot/lib') i określając tę ​​ścieżkę w konfiguracji CMake. Jest to dalekie od komfortu np. Java z Maven lub Go z 'go get'. –

+0

Czy ktoś próbował Shake z D? http://community.haskell.org/~ndm/shake/ – Arlen

Odpowiedz

2

Zdaję sobie sprawę mój komentarz rzeczywistości może być odpowiedzią na pytanie, więc tutaj jest:

proces rozwoju D nie może być inna niż podobne w C lub C++ świata. Czy to naprawdę trudne do zobaczenia? Prawie wszystkie kompilatory C i C++ generują "natywny" kod. D nie jest wyjątkiem. Był projekt D.NET, który może być ukierunkowany na .NET, ale jest nieaktywny przez lata ...

Ponadto, wszystkie narzędzia używane w projektach opartych na C/C++ mogą być z łatwością wykorzystane do czegokolwiek innego. CMake może być również używany w projektach Java lub .NET. To samo dotyczy Make i/lub Autotools. Dlaczego Maven i Ant bardziej popularne w świecie Java to inna historia.

Mówiąc o nich, możesz użyć Mavena lub Mrówki w procesie rozwoju D! Mówiąc prościej, musisz napisać własne wtyczki Mavena, aby uczynić je łatwiejszym i bardziej elastycznym, ale jest to wykonalne i byłoby naprawdę bardzo fajnym projektem.

Z tego, co widziałem, programiści D przylepiają się do dobrej, starej marki lub piszą skrypt BASH, aby wykonać całą operację. Jednak widziałem ludzi z fundacji używać WAF. Jeśli jesteś programistą Python, po prostu pokochasz WAF. Jeśli nie, spróbuj podobnych rzeczy - widziałem ludzi używających SCons, Remake, Premake, itp ...

DSSS+Rebuild jest najbliższy bardzo przydatnemu narzędziu zrobionemu z D. Niestety są to martwe projekty. :(

pracuję nad narzędziem Maven stylu, ale biorąc pod uwagę ilość czasu mam - będzie użyteczny w 2014 roku :)

Źródło

2013-01-17 19:21:54 DejanLekic

+1

Właściwie proces budowania D bardzo różni się od C \ C++. C \ C++ używa plików nagłówkowych i trzeba tylko przekompilować plik implementacji, jeśli zostanie zmieniony, jeśli jeden z plików nagłówkowych zostanie zmieniony, jeśli jeden z plików nagłówkowych 'include'd w pliku' header's zawarte przez ten plik i tak dalej. Jeśli dokonasz zmiany w pliku implementacji, musisz tylko przekompilować ten plik. D jest inne - API i implementacja są w tym samym pliku, a D silnie polega na metaprogramowaniu szablonów, więc jeśli coś zmienisz, będziesz musiał przekompilować wszystko. To sprawia, że ​​przyrostowe kompilacje są niemożliwe. –

+0

@IdanArye: Dobry komentarz. To główny powód, dla którego pytam. Tradycyjne narzędzia do kompilacji wymagają ręcznego określania zależności.Nie zawsze jest to prawdą w procesie budowania D. Na przykład podczas używania DMD możesz wygenerować pliki interfejsu D (.di), aby przyspieszyć działanie, ale nie musisz tego robić. –

+0

Zgadzam się z Idanem, ale nie chciałem wchodzić w szczegóły. W końcu nie chodziło o to, ale o cały cykl życia, jeśli się nie mylę. :) – DejanLekic

 Powiązane problemy

  • Brak powiązanych problemów^_^