Newsgroup: it.comp.programmare
Titolo: Struttura delle directory di sviluppo

Quando si sviluppa del software, si potrebbe tenere tutti i sorgenti in 
una sola directory, e tenere in quella stessa directory anche 
(eventuali) file intermedi, e file eseguibili.
Oppure si possono porre i file intermedi in un'altra directory, e i file 
eseguibili in un'altra ancora.
Inoltre, se il progetto comporta la creazione di piu' moduli eseguibili 
(programmi o librerie), i relativi sorgenti possono essere posti in 
directory distinte oppure no.
Infine, se si vogliono mantenere piu' versioni eseguibili per lo stesso 
modulo eseguibile (per esempio, una a scopo di debugging e una a scopo 
di rilascio), si possono avere altrettante directory.
La domanda che pongo e' la seguente:
Ci sono nel Web articoli che, relativamente a un progetto di sviluppo 
software, consiglino come organizzare le directory in cui sono contenuti 
i sorgenti e i file da essi generati?
Grazie
-- 
Carlo Milanesi
http://digilander.libero.it/carlmila

 i sorgenti e i file da essi generati?
Non lo so. Ci sara' sicuramente qualcosa.
Ma escludo che vi sia una regola fissa.
Tendenzialmente si finisce con l'adottare tacitamente quanto proposto
dall'IDE, e poi ci si abitua.
Vale sempre il principio che "finche' funziona, perche' cambiare..."
Poi a fronte di nuove situazioni, o numero di file esageratemente grosso a
cui segue l'immancabile perdita del tal sorgente per sovrascrittura,
allora uno si rimbocca le maniche e trova una soluzione piu' adeguata al
problema.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Vale sempre il principio che "finche' funziona, perche' cambiare..."
Un problema che incontro e' il seguente.
Scrivo una libreria in un certo linguaggio (diciamo in linguaggio C), 
che possa essere richiamata da programmi scritti in altri linguaggi 
(diciamo C#).
Voglio scrivere un programma di test white-box con possibilita' di 
debugging per tale libreria, e a tale scopo scrivo un programma nello 
stesso linguaggio usato per la libreria, che incorpora gli stessi file 
che fanno parte anche della libreria.
Infine, voglio scrivere un programma di test black-box che invochi la 
libreria da un altro linguaggio.
Quindi la situazione dei sorgenti e' la seguente:
- Progetto "Libreria": Genera una DLL per Win32.
   - file1.h
   - file1.c
- Progetto "WhiteBoxTest": Genera un programma Console per Win32.
   - file1.h (non e' una copia, ma un riferimento al file di sopra).
   - file1.c (non e' una copia, ma un riferimento al file di sopra).
   - main.c
- Progetto "BlackBoxTest": Genera un programma Windows Form per .NET.
   - file2.cs
Quando si esegue il programma generato dal progetto "BlackBoxTest", sia 
in modalit� debugging, che in esecuzione libera, la DLL generata dal 
progetto "Libreria" deve trovarsi nella stessa directory in cui si trova 
il programma stesso.


 comportamenti diversi.
Io lo depreco al punto che mi devo prendere dei sedativi
per non incazzarmi. Non gli ci voleva niente a permettere
differenti organizzazioni e - sarò maligno - mi sembra uno
dei 100.000 piccoli impicci che mamma microsoft mette in
mezzo per scoraggiare portabilità e altre cosette utili
del genere. Non ho detto "impedire", eh...
Comunque, per quel che vale, io faccio come te.
ciao
Apx.

 Comunque, per quel che vale, io faccio come te.
Scusate, ma io che per fortuna non ho mai avuto il dispiacere di mettere
le mani in quella roba che usate voi, ma utilizzo ancora il sano vecchio
makefile, possibile che non ci sia modo di inserire delle opzioni per il
compilatore?
Il mio editor, che e' un editor, ha la possibilita' di richiamare dei
compilatori esterni associati al tipo di linguaggio e se io gli dico di
usare il gcc e gli opportuni parametri, lui lancia il gcc con quei
parametri che mi permettono di impostare le directory di destinazione sia
degli oggetti intermedi che dell'eseguibile.
E l'ambiente nativo di dotnet non ha questa banale possibilita'?
Magari c'e' ma e' nascosta bene...


Carlo Milanesi ha scritto:

Amico, usa Eclipse ed i tuoi progetti verranno gestiti
in automatico alla grande.

 in automatico alla grande.
Mi puoi accennare a dove vengono messi i vari file generati da Eclipse 
per un programma, diciamo, in C++?
Per esempio, crea una directory per i sorgenti, una per i file intermedi 
e una per i file target o mette tutti i file nella stessa directory?


Carlo Milanesi ha scritto:

Mah, non uso Eclipse per il C++, ma per Java.
Comunque, la gestione dovrebbe essere simile:
cioï¿œ vengono raggruppati i sorgenti e i compilati in alberi
di directory distinti. Non sarebbe di grande utilitï¿œ mischiare
tutto in un unico calderone.
Secondo me fai prima a scaricarlo e provarlo:
Eclipse IDE for C/C++ Developers
http://www.eclipse.org/downloads/packages/eclipse-ide-cc-developers/galileosr1

 sono contenuti i sorgenti e i file da essi generati?
Mah...  se metti i file "obj" in una directory completamente separata da quella del tuo progetto, dovrai ricompilare tutto ogni 
volta che prenderai in mano una versione diversa del tuo progetto.  Mi spiego:
in C:\MioLavoro\AnalizzatoreDiPassere     i file sorgente che compongono il mio progetto "AnalizzatoreDiPassere"  :-)
in C:\FileOggetto\AnalizzatoreDiPassere     i file oggetto del progetto "AnalizzatoreDiPassere"
In tal caso, se ogni tanto copierai C:\MioLavoro\AnalizzatoreDiPassere  in  C:\MioLavoro\AnalizzatoreDiPassere-old, nel momento in 
cui vorrai tornare ad usare la vecchia versione, dovrai ricordarti di fare un rebuild-all, altrimenti i file oggetto nella directory 
C:\FileOggetto\AnalizzatoreDiPassere  avranno una data/ora  pi� recente del file sorgente e quindi non si ricompiler�.
Sarebbe meglio tenere gli oggetto in una SUB-directory del progetto:
C:\MioLavoro\AnalizzatoreDiPassere\obj
cosi' gli oggetto seguiranno i sorgenti.
Prima di archiviarli devi semplicemente cancellare la subdirectoy obj.
Marco

 Comunque, la gestione dovrebbe essere simile:
Oddio, spero proprio di no. La struttura delle directory usata per i
progetti Java � una pura e semplice perversione...


 
Beh � una bellissima perversione, in quanto io nemmeno
me ne accorgo quando programmo... ;-)

 me ne accorgo quando programmo... ;-)
E' proprio quello il problema...


 
ma io godo... ;-)