boost 1.68 übersetzen
-
Hallo,
von Hause aus unterstützt das RAD Studio 10.2 leider nur die boost Bilbiotheken 1.55 (für den clang compiler). Da in 1.66 ein paar (für uns) brauchbare Sachen dazugekommen sind möchte ich die 1.68 für das Studio bauen. Und da fangen die Probleme an
Als Toolset wird borland angeboten, aber das ist, soweit ich weiß, der klassische Compiler. Für den bcc32c gibt es wohl kein Toolset, wie bringe ich bjam/b2 denn bei, den clang zu benutzen?
Hat das überhaupt schon mal jemand gemacht? Im Netz finde ich jedenfalls so gut wie keine Infos dazu.
-
Wenn du Clang verwendest dann verwende Clang ... nen?
-
One does not simply use clang.exe.
Bei Embarcadero arbeiten nämlich die superschlauen Leute, die haben mit bcc32c.exe ´nen Wrapper um die compclang33.dll gebaut, damit der bcc32 und bcc32c die gleichen Aufrufkonventionen unterstützen. Und boost unterstützt mit dem borland Toolset nur den bcc32, aber nicht den bcc32c. Aber soweit komme ich nicht mal, wenn ich "bootstrap.bat borland" Aufrufe steigt mir die Batch Datei schon mit "Das Sprungziel - Test_Path wurde nicht gefunden" aus. Und da der Borland/Embarcadero/Idera Support von boost eingestellt wurde und das borland Toolset nur bis zum Borland Developer Studio 2006 unterstützt wird habe ich mir gedacht, ich frag mal vorsichtig nach, ob das schon irgendjemand hingefummelt bekommen hat. Denn darauf wird´s hinauslaufen - iwie zusammenfrickeln.
-
Damn. Aber was wäre wenn du die Clang Version auf die RAD Studio aufbaut einfach zusätzlich installierst, und dann damit die Boost baust? Die werden ja wohl hoffentlich nicht das Object-File Format oder die ABI geändert haben. Oder etwa doch? Das wäre dann natürlich sehr sehr doof.
Falls es fertig wirklich nicht geht: Die Doku von Boost.Build ist nicht gerade übersichtlich. Und zum Thema eigene "Toolsets" zu Definieren hab ich nicht viel gefunden. Hier steht was über die vordefinierten Complier: https://boostorg.github.io/build/manual/develop/index.html#bbv2.reference.tools.compilers
Im Prinzip gibt's da für jeden Compiler ein Jamfile wo das Toolset definiert wird wenn ich mich recht erinnere.Gibt aber ne Boost.Build Mailing Liste. Wenn du da mal nett fragst und viel Glück hast... naja wäre zumindest nen Versuch wert.
Und dann ist da natürlich noch die Frage ob Boost.Config überhaupt RAD Studio unterstützt. Wenn sich der Compiler genau wie die Clang Version verhält auf der er aufbaut, dann wird es vermutlich hinhauen. Wenn nicht, dann wird es "lustig". (Wobei du diesen Teil zumindest mal mit ein paar Header-Only Libraries testen kannst. Wenn das Zeug geht, dann hast du ne gute Chance dass eine passende Toolset-Definition für Boost.Build reicht.)
Davon abgesehen wäre es aber vermutlich gut auf nen anderen Compiler zu wechseln. Also falls das auch nur irgendwie denkbar wäre, dann ... denk mal darüber nach
Und ich würde an deiner Stelle den Support von Embacadero kontaktieren und denen klar machen dass ein Compiler mit dem man Boost nicht verwenden kann ein qualmender Haufen Scheissdreck ist.
-
Du sprichst mir aus der Seele...
Aber zu deinen Antworten:
Der Linker vom RAD Studio benutzt das OMF Binärformat und kein COFF. Und ich befürchte, der bcc32c erzeugt ebenfalls OMF. Jedenfalls sahen die obj-Dateien, die ich mir angeguckt habe, so aus. Ich glaube, dass der Original clang ELF erzeugt, von dem ich nicht weiß, ob der RAD Studio Linker damit klarkommt.
Boost 1.68 ist nur ne Chromleiste, wirklich brauchen tue ich nichts seit 1.55. Die process Library wäre nett zu haben, da ich was Ähnliches eher schlecht als recht selbst geschrieben habe, und da sind die boost Dinge sicher besser. Die process Library scheint Header-only zu sein, ich probier das einfach mal aus. Damit jetzt mehrere Tage zu verbrennen habe ich nicht vor.
Ein Compilerwechsel kommt für uns leider nicht infrage. Ich bringe das Thema immer wieder auf den Tisch, aber unsere Software ist über 20 Jahre gewachsen. D.h. es existiert oft keine Trennung zwischen Logik und GUI und es werden exzessiv Delphi-Datentypen statt C++-Standarddatentypen benutzt. Unterm Strich heißt dass, dass man 80% der Software besser neu schreibt statt zu portieren. Kann man der Geschäftsleitung schlecht verkaufen, obwohl da Einsicht zu erkennen ist.
Und was den Support von Embarcadero angeht... da musste ich tatsächlich lachen. Es gibt de facto keinen Support. Als Bestandskunde bist du denen sch...egal. Das Einzige was zählt sind Neukunden, das sieht man an deren Marketing. Buzzwords aktueller Technologien, Cross-Platform-Development, etc, pp. Alles eher halbherzig umgesetzt, funktioniert nur für einfache Anwendungen und sobald es in´s Detail geht strotzt das RAD Studio mit Bugs. Freie Bugfixes gibt es nicht, Updates selbst für kritische Bugs (habe selbst zwei Showstopper im Codegenerator gefunden) gibt es nur für kostenpflichtige Subscriptions. Außerdem gibt es kaum User, die C++ mit dem Ding machen, ich denke mehr als 90% machen Delphi. Auf einer Roadshow vor 1.5 Jahren gab es unter knapp 80 Teilnehmern drei C++ User, und dementsprechend viel Bedeutung wird den C++ Usern auch geschenkt. 2016 gab es den ersten 32bit Compiler für C++11, der dermassen buggy war, dass er nicht zu gebrauchen war. Das nächste Major Release hat die Codegenerator Bugs gefixt und produziert korrekten Code, zeigt beim Debuggen aber nicht alle Variablen oder Variablen mit falschem Inhalt an. 2017 gabs das nächste Major Release, das dann vollmundig mit umfangreichen Debugmöglichkeiten beworben wurde. Bezeichnend ist auch dass sie 5 Jahre für den ersten C++11 Compiler gebraucht haben und 2018 immer noch auf clang 3.2 oder 3.3 setzen. Kannst dir jetzt also vorstellen, was passiert, wenn ich mich an deren Support wende und nach Unterstützung für ein boost build frage. Wenn dem Hausmeister gerade langweilig ist hat der vielleicht Zeit für mich und ein wenig Smalltalk, aber mehr auch nicht.
Und deswegen möchte ich eigenlich jeden anschreien, der neu mit dem RAD Studio anfängt, dass er eine andere Suite benutzen soll. Egal welche, sie ist 100%ig besser als das RAD Studio. Jedenfalls, wenn man C++ machen will.
So, genug gejammert, aber das musste mal raus.
Euch allen noch einen schönen Tag und entspanntes Wochenende
-
Kurze Rückmeldung:
Es reicht nicht einfach aus, den boost/process Ordner zu kopieren und versuchen zu übersetzen. Da hängen noch mind. zwei weitere Bibliotheken dran( boost.core und boost.winapi), die man per Präprozessor-Defines an seinen Compiler anpassen muss, wenn es kein Toolset für den verwendeten Compiler gibt. Hab mich da 1.5 Tage lang mit beschäftigt, nicht hinbekommen und boost 1.68 für das RAD Studio 10.2 abgehakt.
Vllt gibts von Embarcadero ja iwann einen aktuelleren Port.
