dead

[legacy]

• 

dead

[Z80Fan]

• 

Questo tool (che te lo linko solo perchè lo ho scoperto ieri e quindi ho ancora la pagina aperta, non per altro) crea dei grafici delle dipendenze; non so se puoi usarlo per tirare fuori qualcosa di utile.

(perche', in assenza di prototipi assume che siano le function calls abbiano parametri default)

Sei sicuro che non ci sia qualche switch in GCC che gli dice di non fare ste cose e non compilare una chiamata se non ha un prototipo? (che tra l'altro sono pure stupito che i moderni standard C [o per lo meno i moderni compilatori] continuino a seguire una regola così arcaica e oltretutto pericolosa).


Cmq se tutta sta roba la vuoi usare su Linux, puoi sempre usare un compilatore C++ e compilare il tuo sorgente C forzando il compilatore a trattarlo come C++; hai la limitazione che devi usare l'intersezione delle feature dei due linguaggi (che però è il 99% del C), ma hai il vantaggio che puoi sviluppare nell'ambiente più "ristretto" del C++ (più strong typing, meno "boh forse intendeva così"), e in qualsiasi momento per una "release" puoi compilare usando un vero compilatore C (magari perchè hai un target che non ha compilatore C++).


(PS: da come hai scritto credo che intendi le dipendenze inter-modulo, ovvero tra i moduli, e non intra-modulo, ovvero all'interno del singolo modulo).

[Z80Fan]

• 

Più che altro la mia idea di usare il compilatore C++ era che tu sviluppi il modulo (che ne so, una lista concatenata per dire una boiata) su un computer potente usando il compilatore C++ e facendo i test del caso, e quando hai appurato che il modulo funziona e compila senza "misteri", puoi usare il sorgente (che comunque sarà sempre C) in qualsiasi compilatore C, anche sul macinino più scarso.

Praticamente ti fai un ambientino dove ti fai il modulo e i vari unit test, e ciò lo fai girare sul computer potente e col compilatore C++. Ogni volta che fai una modifica al modulo, lo ricompili col C++ e ci fai girare i test. Se passa tutto, ti prendi il .c e il .h e lo metti nella tua applicazione del macinino che vuoi.
Addirittura potresti gestire tutto con un repo Git, e attivare delle azioni di pre-commit che automaticamente:
- compilano i sorgenti del modulo, rifiutando il commit se la compilazione non passa;
- eseguono tutti gli unit test del modulo, rifiutando il commit se uno dei test non passa;
- [se tutto va a buon fine] accetta il commit e copia il .h e .c in una cartella a tua scelta, chessò, magari anche una cartella che esporti in NFS così se devi compilare su un macinino, fai un symlink alla cartella NFS così lui compila sempre con il modulo più aggiornato.

Importante è che, se mai fai qualsiasi modifica al C mentre debuggi in un macinino, prima possibile riporti la modifica nel tuo repository principale e rifai girare la compilazione C++ e i test, così sei sempre sicuro di non aver inserito per sbaglio qualche linea dagli effetti misteriosi (che appunto il compilatore C del macinino non va a trovare).

E' uno sviluppo un po' contorto, però assumendo che questi moduli vengono scritti una volta e riusati tante, per la tua particolarissima situazione credo sia meglio procedere così.
La cosa più comoda sarebbe ovviamente avere un transcompilatore C++ -> C, però come avevamo visto molto tempo fa l'unico compilatore che faceva una cosa del genere era una vecchissima versione di Clang che ora non è più supportata.