1. Zuhause
  2. Frage und Antwort
  3. D Entwicklungsprozess

D Entwicklungsprozess

2013-01-17 4 views
7

Was ist der empfohlene Entwicklungsprozess für D-Programme, die Pakete verwenden, die von github geklont und separat erstellt werden?D Entwicklungsprozess

Regel in Bezug auf, wie C/C++ Projekte gebaut verwenden machen, Autotools, Cmake usw.

Die meisten anderen Build-Spezifikationen haben ein Ziel installieren. Sollte es ein Installationsziel im Build geben oder sollten wir einfach eine Bibliothek direkt von dort verlinken, wo sie platziert wird, wenn sie gebaut und hinzugefügt wird, wird sie in D_INCLUDE_PATH eingefügt und dann direkt an sie gerichtet unter Verwendung von DFLAGS=-I<D_INCLUDE_PATH>?

Quelle

2013-01-17 Nordlöw

+1

+1 für die Frage. Vor einiger Zeit habe ich auch danach gesucht und konnte nichts finden. Beendet mit CMake für meine eigenen Projekte und manuell installieren Bibliotheken zu persönlichen Root wie '~/Droot '(also die Bibliotheken waren in' ~/Droot/lib') und Angabe dieser Pfad in CMake-Konfiguration. Dies ist weit entfernt von der Bequemlichkeit von z. Java mit seinem Maven oder Go mit seinem 'go get'. –

+0

Hat jemand Shake mit D versucht? http://community.haskell.org/~ndm/shake/ – Arlen

Antwort

2

Ich weiß, mein Kommentar tatsächlich eine Antwort auf die Frage sein kann, so ist es hier:

D Prozessentwicklung kann in C oder C++ Welt nicht anders sein ähnlich als. Ist das wirklich schwer zu sehen? Fast alle C- und C++ - Compiler erzeugen "nativen" Code. D ist keine Ausnahme. Es gab das D.NET-Projekt, das auf .NET abzielen konnte, aber es ist seit Jahren inaktiv ...

Darüber hinaus können alle Tools, die in C/C++ basierten Projekten verwendet werden, problemlos für alles andere verwendet werden. CMake kann auch in Java- oder .NET-Projekten verwendet werden. Gleiches gilt für Make und/oder Autotools. Warum sind Maven und Ant in der Java-Welt beliebter?

Apropos, Sie können Maven oder Ant im D-Entwicklungsprozess verwenden! Hands down, Sie müssen Ihre eigenen Maven-Plugins schreiben, um es einfacher und flexibler zu machen, aber es ist machbar und wäre in der Tat ein sehr schönes Projekt.

Von dem, was ich gesehen habe, bleiben D Programmierer auf dem guten, alten Make, oder schreiben BASH-Skript, um die ganze Sache zu machen. Allerdings habe ich Leute aus der Lycus Stiftung WAF verwenden gesehen. Wenn Sie Python-Programmierer sind, werden Sie einfach WAF LIEBEN. Wenn nicht, versuche ähnliche Dinge - ich habe Leute gesehen, die SCons, Remake, Premake usw. benutzen.

DSSS+Rebuild ist die nächste Sache zu einem sehr nützlichen Tool mit D. Leider sind sie tote Projekte. :(

Ich arbeite an einem Maven-Stil-Werkzeug, aber in Anbetracht der Höhe der Zeit, die ich habe - es wird verwendbar sein im Jahr 2014 :)

Quelle

2013-01-17 19:21:54 DejanLekic

+1

Eigentlich ist D-Erstellungsprozess sehr verschieden von C \ C++. C \ C++ verwendet Header-Dateien, und Sie müssen nur eine Implementationsdatei neu kompilieren, wenn sie geändert wird, wenn eine der Header-Dateien '' Include's geändert wird, wenn eine der Header-Dateien '' 'in' Header'-Datei beinhaltet von dieser Datei enthalten und so weiter. Wenn Sie eine Implementierungsdatei ändern, müssen Sie diese Datei nur neu kompilieren. D ist anders - API und Implementierung sind in der gleichen Datei, und D verlässt sich stark auf Template-Metaprogrammierung. Wenn Sie also etwas ändern, müssen Sie alles neu kompilieren. Dies macht inkrementelle Builds unmöglich. –

+0

@IdanArye: Guter Kommentar. Dies ist der Hauptgrund für meine Frage. Bei traditionellen Build-Tools geht es oft um die manuelle Angabe von Abhängigkeiten.Dies gilt nicht immer für den D-Build-Prozess. Wenn Sie beispielsweise DMD verwenden, können Sie D-Schnittstellendateien (.di) generieren, um die Geschwindigkeit zu erhöhen, müssen dies aber nicht. –

+0

Ich stimme Idan zu, aber ich wollte nicht auf solche Details eingehen. Nach all der Frage ging es nicht um diese, sondern um den gesamten Lebenszyklus, wenn ich mich nicht irre. :) – DejanLekic

Verwandte Themen

 Verwandte Themen