Abhängigkeitsbaum für C

[xybit]

Hallo zusammen,

hab eine relativ grosse Software in C, deren gesamt Compile eine halbe Ewigkeit dauert. Jetzt kam mir die Idee, das ganze parallel zu gestalten. Dafür benötige ich allerdings die Abhängikeiten, welche Shared Module zur Verfügung stehen müssen, wenn ein anderes Modul kompiliert wird.

Wüsstet ihr vielleicht ein Tool, mit dem ich sowas generieren bzw. analysieren kann?

Schon jetzt danke für eure Antworten und viele Grüsse!

 

[dermoritz]

Darüber solltest du dir selbst keine Gedanken machen. Genau das ist die Arbeit des Compilers. Ich habe das mal kurz gegoogelt und das gefunden:

https://interrupt.memfault.com/blog/improving-compilation-times-c-cpp-projects

make parallelisiert wenn man es sagt:

"-jN" wobei N die Anzahl der Threads ist.

Der Artikel scheint insgesamt sehr hilfreich. den würde ich erstmal lesen.

 

[xybit]

Normal schon, leider befinde ich mich auf einer z/OS Umgebung, da muss man für jedes Modul den Compile Job manuell anstossen. Bisher wurde das sehr rudimentär ohne jedwede Logik gelöst. Dies würde ich aber gerne ändern Doch dafür benötige ich eben genau den Graph.
Oder gibt es einen Weg, den Graph vom Compiler ausgeben zu lassen? Dann würde ich den Code auf einem anderen OS kompilieren und das Verhalten dann adaptieren.

 

[dms]

z/OS Umgebung

.. dann schreib das doch gleich bist doch seit fast 20 jahren hier angemedlet

.. für einen Windows-Compiler hätte ich zum RESMON und zB TEMP im Ramdisk vorgeschlagen


A) welcher Compiler ist es denn (oder gibts da nur einen) und

B) warum denn immer MAKE_ALL - es reicht doch neue Objekte zu kompilieren und dann macht der Linker den Rest

C) gibts eigentlich noch die z/OS Personal Edition für X86 als alternatigve Cross-Compile-Umgebung?


Aber ich habe seit der RM 400 (Sinix) nüscht mehr ausserhalb der GCC Welt auf Servern kompiliert

 

[xybit]

Hab das Projekt unfreiwillig aufs Auge gedrückt bekommen, nachdem die Verantwortlichen genauso alt wie das Projekt geworden sind

A) welcher Compiler ist es denn (oder gibts da nur einen) und

B) warum denn immer MAKE_ALL - es reicht doch neue Objekte zu kompilieren und dann macht der Linker den Rest

C) gibts eigentlich noch die z/OS Personal Edition für X86 als alternatigve Cross-Compile-Umgebung?

Ehrlich gesagt bin ich da selbst (noch) überfragt, wie die jung da arbeiten. Muss mich da erst noch tiefer einarbeiten.

.. für einen Windows-Compiler hätte ich zum RESMON und zB TEMP im Ramdisk vorgeschlagen

Hm, kannst du deinen RamDisk Ansatz bitte kurz näher beschreiben?

 

[dms]

Hm, kannst du deinen RamDisk Ansatz bitte kurz näher beschreiben?

ich bin ja auch ein alter Mann, man hat "früher" das TEMP der Kompileumgebung in einen RAMDISK gelegt weil das einfach IOPS ohne Ende passierten - eine NVME wird heute schnelle genug sein

aber man kann ja mal mit dem Resmon schauen, ob überhaupt Zeiten im Filesystem bleiben oder ein Parallel Make auf mehr Cores zielführender ist


mal ein etwas nicht so alter Artikel

https://interrupt.memfault.com/blog/improving-compilation-times-c-cpp-projects

 

[xybit]

Danke dir, das klingt plausibel, ich schau mir die Sache mal näher an

 

[Sqrt(-1)]

Object file compiler caching (wie z.B. ccache) kann auch erhebliche Beschleunigungen bewirken.