In-Source-Build vs. Out-Of-Source-Build

In meiner (hauptsächlich C ++) Entwicklung habe ich mich lange an die Verwendung von Out-of-Source-Builds gehalten. Das heißt, meine Quelle sitzt in der Regel in einem /project/srcVerzeichnis und die Builds leben in einer /project/build/bin/release, /project/build/bin/debugVerzeichnisse. Ich habe dies getan, weil dadurch meine Quellverzeichnisse von Zwischendateien befreit werden, ich einen Speicherort für alle meine Binärdateien habe, das Packen einfacher, das Reinigen einfacher und die Versionskontrolle einfacher ist. (Habe ich etwas vergessen?)

Ich erbe jetzt ein (großes) Projekt, das In-Source-Builds verwendet. Was ist die Motivation für diese Art von Struktur und was sind ihre Vorteile? (Ich beschäftige mich am meisten mit Gründen auf technischer Ebene im Vergleich zu Gründen mit persönlichen Präferenzen.)

Ich hatte gehofft, Lakos '"Large-Scale C ++ Software Design" hätte sich darauf ausgewirkt, aber ich habe es verpasst, wenn es so wäre.

— DiB
quelle

Entschuldigung. Ich suche nach "In-Source-Builds verbessern 'x'" oder "sie helfen dabei, 'y' sicherzustellen" oder "automatisierte Tests können dann 'z'". Kein Scherz. Ich möchte hier ausdrücklich nicht in einen Meinungskrieg geraten!

— DiB

In-Source-Builds sind ein Fluch, den Sie der Faulheit Ihres Vorgängers verdanken. Sie sind für fast alles schrecklich (Quellcodeverwaltung, Crossbuilding, Textsuche usw.), aber mit bloßen Makefiles unglaublich einfach zu erstellen. Entschuldigung, das war ein Scherz. Aber eine objektive .

Was genau meinst du mit "In-Source" Builds? So etwas wie /project/src/bin/releaseoder wirklich alle Zwischen- und Ausgabedateien in /project/src? Letzteres kann in der Tat ein Chaos sein, wenn es mehr als ein Dutzend Quelldateien gibt, Ersteres ist in Ordnung.

— Doc Brown

@Tibo, es ist nicht nur unglaublich einfach mit Makefiles, sondern scheint auch bei den meisten IDEs die Standardeinstellung zu sein (zumindest als ich vor ein paar Jahren das letzte Mal nachgesehen habe).

— Bart van Ingen Schenau

@BartvanIngenSchenau Wirklich? Welche IDE haben Sie verwendet, wo dies der Fall ist? Qt tut dies nicht, tatsächlich scheint es den Build so weit wie möglich von der Quelle entfernt zu platzieren. Eclipse tut dies nicht. Sie könnten argumentieren, dass Clion dies irgendwie tut, aber nur als Folge von main.cpp Wenn Sie sich zunächst in der obersten Ebene Ihres Projekts befinden, wird auf dieser obersten Ebene immer noch ein separates cmake-Erstellungsverzeichnis außerhalb Ihrer Quelle erstellt. Ich glaube, dass MSVS auch in dieser Hinsicht Clion ähnlich ist.

— Wann

Nachdem ich die Community hier gefragt und meine Online-Suche fortgesetzt habe, konnte ich keine wesentlichen technischen Gründe für die Verwendung von In-Source-Builds finden. (Es gibt viele Beispiele für Gründe, sie zu vermeiden.)

Der einzige objektive Grund, den ich gefunden habe (wie im Kommentar von @BartvanIngenSchenau erwähnt), ist, dass In-Source-Builds manchmal von einem Build-System standardmäßig verwendet werden. Aufgrund dieser Standardeinstellung benötigen sie keinen Overhead in der Einrichtungszeit, was für ein sehr kleines (oder Scratch-) Projekt durchaus akzeptabel sein kann.

— DiB
quelle