2013-01-17 14 views
7

Qual è il processo di sviluppo consigliato per i programmi D che utilizzano pacchetti clonati da github e creati separatamente?D Processo di sviluppo

genere in relazione a come/C++ progetti C sono costruiti utilizzando fare, autotools, cmake, ecc

maggior parte delle altre caratteristiche costruttive hanno un target install. Dovrebbe esserci una destinazione di installazione nella build o dovremmo semplicemente collegare una libreria direttamente da dove viene posizionata una volta creata e aggiungere la registrazione che include in D_INCLUDE_PATH e quindi indirizzarla a esse usando DFLAGS=-I<D_INCLUDE_PATH>?

+1

+1 per la domanda. Qualche tempo fa stavo cercando anche questo e non ho trovato nulla. Finito usando CMake per i miei progetti e installando manualmente le librerie su root personale come '~/droot' (quindi le librerie erano in ~ ~/droot/lib') e specificando questo percorso nella configurazione di CMake. Questo è lontano dalla comodità di, ad es. Java con il suo Maven o Go con il suo go get. –

+0

Qualcuno ha provato Shake con D? http://community.haskell.org/~ndm/shake/ – Arlen

risposta

2

mi rendo conto mio commento può effettivamente essere una risposta alla domanda, ecco che è:

processo di sviluppo D non può essere diverso da quello simile in C o C++ mondo. È davvero difficile da vedere? Quasi tutti i compilatori C e C++ generano codice "nativo". D non è un'eccezione. C'era il progetto D.NET che poteva essere utilizzato su .NET, ma è inattivo da anni ...

Inoltre, tutti gli strumenti utilizzati in progetti basati su C/C++ possono essere facilmente utilizzati per qualsiasi altra cosa. CMake può essere utilizzato anche in progetti Java o .NET. Lo stesso vale per Make e/o Autotools. Perché Maven e Ant sono più popolari nel mondo di Java è una storia diversa.

Parlando di loro, è possibile utilizzare Maven o Ant nel processo di sviluppo D! Giù le mani, è necessario scrivere i propri plugin Maven per renderlo più facile e flessibile, ma è fattibile, e sarebbe in effetti un progetto molto bello.

Da quello che ho visto, i programmatori D si attengono al buon vecchio Make o scrivono lo script BASH per fare tutto. Tuttavia, ho visto persone della fondazione Lycus utilizzare WAF. Se sei un programmatore Python, ti piacerà solo WAF. In caso contrario, prova cose simili: ho visto persone usare SCons, Remake, Premake, ecc ...

DSSS+Rebuild è la cosa più vicina a uno strumento così utile realizzato con D. Sfortunatamente sono progetti morti. :(

Sto lavorando su uno strumento di esperto di stile, ma considerando la quantità di tempo che ho - sarà utilizzabile nel 2014. :)

+1

In realtà, il processo di costruzione D è molto diverso da C \ C++. C \ C++ usa i file di intestazione e devi solo ricompilare un file di implementazione se è cambiato, se uno dei file di intestazione è 'include's modificato, se uno dei file di intestazione' include'd nel file 'header's incluso da quel file e così via. Se apporti una modifica in un file di implementazione, devi solo ricompilare quel file. D è diverso: l'API e l'implementazione sono nello stesso file e D si basa pesantemente sulla metaprogrammazione del modello, quindi se cambi qualcosa devi ricompilare tutto. Ciò rende impossibili le build incrementali. –

+0

@IdanArye: buon commento. Questa è la ragione principale per cui chiedo. Gli strumenti di compilazione tradizionali servono molto a specificare manualmente le dipendenze.Questo non è sempre vero per il processo di compilazione di D. Ad esempio, quando si utilizza DMD è possibile generare file di interfaccia D (.di) per accelerare le cose ma non è necessario. –

+0

Sono d'accordo con Idan, ma non volevo entrare in questi dettagli. Dopo tutto, la domanda non riguardava quelle, ma il ciclo di vita complessivo, se non mi sbaglio. :) – DejanLekic