Mehrere Tools von uns verwenden gemeinsame Sourcen. An sich ned schlecht, und soll auch weiter ausgebaut werden.
Ich bin nun mit fuer die Basis verantwortlich, erzeuge Schnittstellen und Pflege / Dokumentiere ein teil der gesharedten Sourcen.

Nun hab ich aber Kollegen mit im Boot, die lieben es, cpp Dateien zu verteilen. Das heisst, ich finde teilweisse Projekte vor, wo nur ne kleine Anzahl von eigenen cpp dateien bestehen, aber eine unmenge von cpp dateien aus anderen Projecten eingebunden sind, mit teilweisse recht abenteuerlichen verlinkungsmechanismen. Die Kroenung sind dann so Verzeichnisshirarchien, wo header und cpp's nebeneinanderliegen und man das in sein Project einbinden soll, was man braucht ... Also pro klasse ein haeder und eine cpp Datei, + die notwendigen Abhaengigkeiten (die natuerlich nirgends richtig dokumentiert sind).

Ich hab selber noch nie gesehen, das man cpp dateien aus anderen Projectstrukturen bei sich "reinlinkt"
Ist das gaengige Praxis ?

Auf meine Frage hin, ob man den Sourcecode ned in libraries (lib) auslagern kann, kommen zig argumente.
klar, der klassiker ist immer dabei: "Da muss ich aber zig Projecte anfassen und aendern"
kommen aber auch andere,
"wenn ich an den sourcen was aendere, muss ich immer erst die lib neu kompilieren" (ja das sein Project noch laenger braucht ... )
"wenn wir mal gegen ne andere libversionen/runtime linken, oder andere compilereinstellungen brauchen, dann sind die libs nimmer kompatibel. Man muesste in die libs informationen mit reinpacken, gegen welche libversion/runtime die gelinkt und mit welchen compilereinstellungen die lib erzeugt wurde. das ist unhandlich und macht viel zu viel overhaed "

Ich wuerde aber gerne Ordnung in den verzeichnissen haben, zumal diese verzeichnisse als SDK zu anderen Firmen rausgehen. Und da hab ich nen ganz schlechtes Gefuehl bei cpp Dateien drinne (auch wenn es ned kritisch ist, das die anderen die sourcen bekommen). Ich weiss ned was andere denken wenn sie in nem sdk so nen verzeichnis-aufbau wie /include/source sehen.

Also kennt jemand bissi Literatur zu dem Thema, wo man paar argumente fuer oder gegen gewisse Strategien bekommt. Ich muss nun grad abwaegen, ob ich das Thema forciere und damit anderen bissi auf die Finger klopfe ...

Ciao ...

Dementsprechend würde ich unterschiedliche strategien verwenden.

2. dann fuer beide. Wenn es zum Kollisionsmanagment kommt, sollten eigentlich alle mit dem Gefuehl, "naja, eigentlich isses besser so" rausgehen ...

Ich mein einfach nur verordnen ala "das darf man nicht", wer weiss was dann fuer Loesungen entstehen wuerden.
Schlimmer iss eigentlich, dass sich externe dadurchfummeln muessen. Deshalb haett ich schon lieber ne Standardisierte Rangehensweisse.

Ciao ...

Schlimmer iss eigentlich, dass sich externe dadurchfummeln muessen. Deshalb haett ich schon lieber ne Standardisierte Rangehensweisse.

Standardisiert war bei mir eigentlich bei jedem arbeitgeber in dieser hinsicht entweder nix (wie bei dir) oder aber jedes projekt hat einen eigenen source tree. und cross linken ist nicht.

das problem mit so einem cross linken ist ja, dass du dann auch die .cpp dateien bearbeitest irgendwann. und wenn du dann die lib nicht buildest sondern nur die .cpp kompilierst und damit effektiv die unit tests umgehst und dadurch zB die ganze lib killen kann.

wenn ich heute abend mehr zeit habe, schreibe ich etwas mehr zu dem thema...