Newsgroup: it.comp.programmare
Titolo: compilazione sorgenti

Ho questa situazione:
### main.C #################################
        #include "pre.inc"
        ...
        codice del main.C
        ...
        #include "post.inc"
### pre.inc ################################
        #include file_1.h
        #include file_2.h
        ...
        #include file_n.h
        #include my_file_1.h
        ...
        #include my_file_m.h
### post.inc ################################
        #include file_1.C
        #include file_2.C
        ...
        #include file_n.C
        #include my_file1.C
        ...
        #include my_filem.C
(uso il g++ sotto linux)
Tenendo presente che:
1)I sorgenti non sono miei io devo aggiungere delle funzionalità aggiungendo      
                              file e facendo piccole modifiche ai sorgenti 
già presenti.
2)Un file .h ha sia la dichirazione che la definizione di classe (non 
chiedetemi perchè non hanno usato l'estensione cpp)
3)Il makefile non esiste poichè viene compilato semplicemente il main.C e 
tutto vien da se.
La domanda è:
Come posso strutturare un Makefile per compilare in modo tale da poter 
rispettare le modifiche fatte nei vari file (l'ovvia utilità del make) e da 
poter fare il debug nei singoli file?
Io ho provato creando un makefile, ma dividendo i vari file oggetto in 
singole compilazioni (per poter fare il debug richiamando -ggdb su ogni 
comando di compilazione (credo sia l'unico modo, vero?...ditemi di no)) ho 
il problema che quando compilo "file1.C" non vede le dichiarazioni che sono 
nel "file2.h"
Come posso ottenere ciò?
Ciao e grazie.
-- 
__________________________________
"Ama e fai c'ho che vuoi".... 
__________________________________

         #include my_filem.C
Mi traggo fuori dal thread originario per una considerazione sullo 
stile/progettazione che mi ronzava in testa da tempo...
Allora, posto che in molti casi e` lecito (nel senso di "funziona uguale" :)
fare, come su quotato,
#include nomefile.c (o equivalenti)
e` considerato un buono stile? Accettabile? Addirittura consigliato/utile in 
qualche caso? 
Personalmente ritengo che se si arriva a questo sarebbe meglio riconsiderare 
la riorganizzazione del codice e la sua distribuzione nei sorgenti, 
ma non ho molta esperienza sul campo...
-- 
Ikitt
*** mailserver: 
freemail.it

Ikitt wrote:

Il progetto in questione ha un totale di 1,4 MB di sorgenti (solo testo)
Inoltre vengo (e programmo anche in) dal Java e sono abituato a porre ogni 
classe in un file. Con il tempo ho capito che questa abitudine aiuta molto 
innanzitutto a organizzare bene il codice, migliora la leggibilità e 
inoltre (come nel mio caso) è più semplice poter 
(escludere/includere/sostituire) classi.
Ciao...


 (escludere/includere/sostituire) classi.
Certo, quello che dici e` "bene", ma in C non si include mai un file .c,
sempre e solo .h, e si deve suddividere le dichiarazioni nei .h e le
funzioni nei .c, poi si usa il linker per mettere insieme il tutto.
Fare un unico sorgente .c che include .h e .c indistintamente e` "male".
Bye.

 (escludere/includere/sostituire) classi.
Sono d'accordo sui vantaggi[1], ma fatico a capire del perche` affidarsi al 
preprocessore invece di usare strumenti come make, ad esempio.
Inoltre, non si potrebbero compilare i singoli sorgenti separatamente
e unire i file oggetto via linker invece di includere insieme?
[1] A parte sul migliorare la leggibilita`, IMHO un "#include pippo.c" non
e` il massimo...


 Bye.
Io, come detto nel messaggio originario, sto modificando/aggiungendo un 
progetto già scritto da altri la cui struttura è del tipo
Sorgenti --> generano un compilatore diciamo X
un file F -> X => genera un file eseguibile che a sua volta è un 
verificatore/simulatore.
Ebbene, c'è di mezzo anche la generazione di codice a partire da un modello 
e la struttura del file F è così:
#include "preamboli.inc"
codice C (no header)
#include "postamboli.inc"
nei preamboli vengono richiamati tutti i file .h
nei postamboli tutti i .C
questo credo sia stato fatto per comodità dato il fatto che il file F viene 
generato da X.
Ciao.
