Für den Aufbau selbst ist bjam der richtige Weg. Folgen Sie einfach der Readme und konstruieren Sie die Befehlszeile. Sie sollten (sollten) es nur einmal pro Boost-Release tun müssen.
Aber es ist nicht nötig, Ihr eigenes Projekt, das Boost verwendet, an das Build-System von Boost anzubinden.
Es gibt keine besonderen Nachteile für die Verwendung von gmake zum Erstellen von C ++ - Code, der Boost.Python verwendet, und das Pro ist, dass es viele Beispiele für die Verwendung von gmake gibt.
Wenn Sie andere Boost-Bibliotheken verwenden wollen, dann mag die Verwendung von bjam sinnvoll sein, aber aus einem einfachen Blickwinkel ist make sehr komplex für ein komplexes Projekt, weshalb zum Beispiel ant entwickelt wurde .
Bjam erweitert andere Projekte, die damit begonnen haben, make zu ersetzen.
Aber auf der anderen Seite ist make auf jedem Unix-Betriebssystem zu finden, bjam ist das nicht, aber wenn Sie Boost-Bibliotheken für Ihr Projekt verwenden müssen, können Sie sicherstellen, dass es eingebunden ist.
Für Ihr Projekt halte ich bjam für die beste Option, aber wenn Sie ein tragbares Projekt schreiben würden, das andere mit ANSI C ++ kompilieren müssten, würde ich vorschlagen, auch GNU Make zu unterstützen.
Ich habe Team-Shared-Build-Frameworks mit Make und BJam erstellt. Meine abschließende Meinung war, dass die bjam-Implementierung einfacher zu warten war, nachdem ich das grundlegende Setup gelernt hatte. Teammitglieder sind anfangs vielleicht resistent, aber sobald sie es benutzen und sehen, dass es viel einfacher ist als Make (meiner Meinung nach), werden sie gewonnen. Einige werden weiterhin widerstehen. Sie können Dual-Build-Systeme einrichten, aber das ist ein zusätzlicher Aufwand.
Wenn ich gezwungen bin, Make zu verwenden, erstelle ich nicht-rekursive Makefile-Lösungen mit zentralen Regelsätzen. BJam hat all das eingebaut.
Tags und Links comparison build-automation makefile boost-bjam