Lapack: Build-Systeme

Um der Liste hinzuzufügen, unterstützen CMake-Builds derzeit (scheinbar) die Option, nur ausgewählte Teile der Bibliothek (REAL, DOUBLE, COMPLEX und/oder DOUBLE COMPLEX) zu erstellen, während reine Makefile-Builds dies nicht tun. (Ich habe die Makefiles in der Kopie, die wir mit OpenBLAS verteilen, geändert und könnte auf Wunsch eine PR erstellen - müsste neu differenzieren, um einige hier nicht relevante Änderungen auszulassen)

CMake-Builds unterstützen derzeit (scheinbar) die Option, nur ausgewählte Teile der Bibliothek zu erstellen (REAL, DOUBLE, COMPLEX und/oder DOUBLE COMPLEX).

Diese Option hat beim letzten Versuch (um Mai 2020) funktioniert.

Der CMake-Build hat mehrere Optionen, die für mich wichtigsten liste ich hier auf:

• Erstellen von gemeinsam genutzten oder statischen Bibliotheken
• aktivierte oder deaktivierte Tests
• 64- oder 32-Bit-Indizes
• optimierte und Debugging-Builds
• Optionen für Matrix Generator Library (TMG), Nutzung anderer BLAS-Bibliotheken, BLAS++, LAPACK++...

Gute Idee. Builds, die auf meiner Maschine mit make funktionieren, aber nicht auf der ci mit CMake, haben mich ein paar Mal verrückt gemacht.

Technisch denke ich, dass das Makefile auch viele dieser Optionen unterstützt (Sie können einfach Ihre make.inc bearbeiten). Wenn Sie einen Build ohne die Tests wünschen, können Sie mit make lib . Entscheidend ist jedoch, dass der Aufbau einer gemeinsam genutzten Bibliothek nicht unterstützt wird. Die meisten Leute verwenden LAPACK als Shared Library, was CMake für mich zum klaren Gewinner macht.

Wenn wir es letztendlich versuchen, schlage ich vor, dass wir der Readme-Datei einige zusätzliche Build-Anweisungen hinzufügen. Wie man die Tests erstellt und ausführt, wie man Flags hinzufügt, insbesondere das Frecursive Flag. Vielleicht sogar ein kleiner Hinweis zur Verwendung der gemeinsam genutzten Bibliothek.

Ich vermute, dass es bereits viele Patches geben wird (zB in Linux-Distributionen, die Lapack packen), um gemeinsam genutzte Bibliotheken mit gmake zu erstellen. Sollte nicht allzu kompliziert sein, eine BUILD_SHARED-Option zu make.inc hinzuzufügen, wie die BUILD_DEPRECATED, die bereits vorhanden ist (und beide sind im CMake-Build ziemlich obskur, es sei denn, man weiß bereits, dass ccmake und cmake-gui existieren).

Sollte nicht allzu kompliziert sein, eine BUILD_SHARED-Option zu make.inc hinzuzufügen, wie die BUILD_DEPRECATED, die bereits vorhanden ist (und beide sind im CMake-Build ziemlich obskur, es sei denn, man weiß bereits, dass ccmake und cmake-gui existieren).

Sie müssen nicht mit ccmake , um eine dieser Optionen festzulegen. Sie können die Befehlszeile ähnlich dem configure Skript verwenden, das von Autotools generiert wird:

$ cmake -DBUILD_SHARED_LIBS=ON -DBUILD_COMPLEX=OFF -DBUILD_DEPRECATED=ON -- ../lapack/
[snip]
-- Build deprecated routines: ON
-- Build single precision real: ON
-- Build double precision real: ON
-- Build single precision complex: OFF
-- Build double precision complex: ON
[snip]
$ git -C ~/lapack rev-parse HEAD
6e125a41a7d4905d905a7467d3239d3f0d14b22c

Sie können sicherlich, mein Punkt ist, dass es außer dem Lesen der CMakelists.txt keine offensichtliche Dokumentation gibt (während die README auf die vorkonfigurierten make.inc-Dateien für gmake verweist). ccmake und cmake-gui zeigen eine Liste der verfügbaren Optionen an, die jedoch für jeden, der neu bei cmake ist, verloren geht.

Wenn wir eine Dokumentation zur Verwendung von CMAKE schreiben, können wir mich als Versuchskaninchen-Benutzer verwenden, da ich CMAKE noch nie verwendet habe.

Wenn ich das ganze Gespräch lese, habe ich das Gefühl, dass das Makefile in LAPACK nur für mich da ist. ;)

Nun, ich weiß nicht.

Ja: Die Pflege mehrerer Build-Systeme führt zu Inkonsistenzen. Also ich sehe das Argument, nur einen zu haben. (Ob CMAKE, Make oder Meson.) (Oh ja, ich habe auch noch nie Meson verwendet, wenn Sie sich fragen.)

Ich mache mir Sorgen, zu CMAKE zu wechseln, weil ich nicht nur nicht weiß, wie man es benutzt, sondern auch nicht weiß, wie es gewartet wird. Es scheint jedoch, dass wir eine wunderbare Community haben, die helfen kann, daher scheint es kein Problem zu sein, an diesem Teil des Projekts nicht mitarbeiten zu können, außerdem sollte ich wahrscheinlich CMAKE lernen.

Alle: Bitte äußern Sie Ihre Meinung in diesem Thread.

Es scheint, dass die meisten von uns gerne (1) Make entfernen und Meson entfernen möchten; (2) nur zu CMAKE wechseln; (3) fügen Sie eine gute Dokumentation zur Verwendung von CMAKE hinzu. Geht in Ordnung.

Ich werde hier und da ein paar E-Mails an andere Paketbetreuer senden, um sie zu fragen, wie es ihnen geht und was ihre Meinung zu diesem Thema ist.

@martin-frbg: Wie wird das in OpenBLAS gemacht?

OpenBLAS hat Makefiles als "traditionelles" Build-System, das "bekanntermaßen funktioniert", und CMAKE als ursprünglich von Benutzern beigesteuerte Alternative, die immer noch eine Warnung aussendet, dass die generierten Dateien möglicherweise nicht genau dem entsprechen, was ein Makefile-Build tun würde.
Ich mag CMAKE nicht besonders, aber ich habe gelernt, funktionierende (wenn auch manchmal unorthodoxe) cmake-Build-Dateien zu erstellen. Meiner Meinung nach sollten die Makefiles bleiben (und ich glaube, dass gmake immer noch weiter verbreitet ist als cmake). Ich kenne die Geschichte der Meson-Unterstützung nicht - _wenn_ dies ein einmaliger "über den Zaun geworfener" Beitrag war, den niemand kennt oder sich genug interessiert, um ihn auf dem Laufenden zu halten, ich denke, es macht wenig Sinn, ihn herumzubehalten.

Ich kenne die Geschichte der Meson-Unterstützung nicht - wenn dies ein einmaliger "über den Zaun geworfener" Beitrag war, den niemand kennt oder sich genug interessiert, um ihn auf dem Laufenden zu halten, hat es wohl wenig Sinn, ihn zu behalten.

Der Meson-Build wurde in PR #311 mit dem Fallschirm in LAPACK gelandet.

Hm. Wenn es in 3.9.0 akzeptiert würde (wenn auch nur als Proof of Concept), würde es etwas seltsam aussehen, es mit der nächsten Veröffentlichung wieder wegzuwerfen...

Ich habe @therault kontaktiert, damit er uns seine Meinung @therault sagt. Danke @therault!

Open MPI verwendet nur autoconf (automake, autoconf, configure, Makefiles).

Für PaRSEC und DPLASMA verwenden wir nur CMake, und um Benutzern zu helfen, die mit der Konfiguration vertraut sind, hat

Ich kenne ein großes Projekt, das versucht hat, sowohl configure als auch CMake beizubehalten. Es entwickelte sich langsam in einer Situation, in der 100 % der Funktionen in CMake verfügbar waren und immer weniger neue Funktionen in configure unterstützt wurden. Ich glaube, dass sie aufgehört haben, die Konfigurationsversion beizubehalten.

Zwei Build-Systeme für einen Code zu pflegen ist schwierig: Theoretisch sollte das Build-System mit jedem Code funktionieren, und somit sollte die Pflege von zweien möglich sein (mit hohen Kosten für die Betreuer, sie synchron zu halten, weshalb die configure in diesem anderen Projekt fallen gelassen wurde, entschied der Betreuer, dass er mit seiner Zeit Besseres zu tun hatte). In der Praxis ist es manchmal notwendig, den Code an das Build-System anzupassen, um die Dinge sauberer zu machen. In diesem Fall muss eines der beiden Build-Systeme Workarounds und Hacks verwenden, um sich wie das andere und in Übereinstimmung mit dem Code zu verhalten.

Am Ende, CMake oder configure, werden beide enttäuschen. Wir sind Programmierer / Mathematiker / wir machen Algorithmen... Zeit damit zu verbringen, zu verstehen, warum auf dieser Maschine mit dieser Kombination von Compilern und Flags der Code nicht richtig kompiliert wird, das mag niemand. Schlimmer noch, der Versuch herauszufinden, wie man das oder das andere mit CMake oder Autoconf macht, wird Sie die Wand hochfahren :) Wenn Sie mit beiden arbeiten, kann ich Ihnen garantieren, dass Sie sich über beide beschweren werden :) beschweren sich zweimal weniger.

Heute befürworte ich CMake aus einem einzigen Grund: CMake leistet gute Arbeit beim Generieren von Ninja-Dateien anstelle von Makefiles. Ninja kompiliert PaRSEC zwei- bis dreimal schneller als Make -j. Vielleicht kann configure/autoconf auch Ninja-Dateien generieren, ich habe es noch nie versucht... Wenn Sie Ninja noch nie zuvor ausprobiert haben und LAPACK eine CMake-Version hat, schlage ich vor, dass Sie cmake -G Ninja ausprobieren (nach der Installation von Ninja auf Ihrem Computer). Zum Kompilieren rufen Sie 'ninja' in dem Verzeichnis auf, in dem Sie cmake anstelle von 'make' ausgeführt haben. Du wirst sehen, das ist unglaublich :)

Ich freue mich, dieses configure-to-cmake-Glue-Skript zu LAPACK beizutragen, wenn Sie daran interessiert sind.
(Um das klarzustellen, dass dieses Skript nicht auf autoconf/m4 basiert, es ist ein einfaches Skript, das configure --with-feature=value in einen Aufruf von cmake -DFEATURE=value umwandelt, mit etwas mehr Feinschliff).

LAPACK verwendet nicht einmal configure - und ich stimme zu, dass es wahrscheinlich mühsam wäre, ein autoconf/automake/configure-basiertes System gleichzeitig mit cmake zu halten, wobei sich die Autotools selbst ständig "entwickeln" und von m4-Makros und so weiter abhängig sind.

Ich mache mir Sorgen, zu CMAKE zu wechseln, weil ich nicht nur nicht weiß, wie man es benutzt, sondern auch nicht weiß, wie es gewartet wird.

Dies ist ein wichtiger Grund, bei Makefiles zu bleiben.

Alle: Bitte äußern Sie Ihre Meinung in diesem Thread.

Der Meson-Build sollte entfernt werden. Niemand verwendet es, niemand weiß, wie man es pflegt, der ursprüngliche Autor hat einen unvollständigen Build eingereicht und ist nie zurückgekommen, nachdem seine Änderungen zusammengeführt wurden. Wie viele Leute wussten, dass es einen Meson-Build gab, bevor ich diese Ausgabe öffnete?

CMake ist ein portables Build-System mit einfacher Syntax und vollständig konfigurierbaren Builds. Man kann dateispezifische, compilerspezifische oder zielspezifische Optionen setzen (zB um selektiv Funktionen zu aktivieren, die nicht in der C-Standardbibliothek enthalten sind, wie gethostname() ). CMake verfügt über eine robuste Objektdateiverwaltung; Auf diese Weise können Sie weiterhin make eingeben, um Ihre Builds zu aktualisieren, auch wenn Sie die Git-Branches gewechselt haben. CMake interagiert gut mit dem Rest des UNIX-Ökosystems: Sie können beliebige Programme aufrufen und auf ihre Ausgabe reagieren. Sie können beispielsweise pkg-config aufrufen, um andere Pakete zu finden.

Das erste Mal, dass ich CMake verwendet habe, war im Jahr 2016 und ich habe es seitdem kontinuierlich verwendet, um Code für Linux-, Mac-, iOS- und Android-Systeme auf x86-, x86-64-, armv7- und aarch64-Befehlssatzarchitekturen zu erstellen. Es ist auf allen gängigen Linux-Distributionen und auf allen Supercomputern verfügbar, auf die ich Zugriff habe (Grid 5000, Jean Zay, JUWELS, GRICAD, Eagle II). Die Supercomputer verfügen normalerweise über mehrere Versionen, einschließlich alter Versionen und sehr neuerer Versionen (3.18+). Die einzige Plattform, bei der ich mit der Verfügbarkeit von CMake zu kämpfen hatte, ist CentOS 7, aber Sie können jederzeit einen CMake-Tarball herunterladen und das Bootstrap-Skript im Tarball verwenden, um CMake nur mit GNU Make zu erstellen.

CMake funktioniert einfach für mich.

Meine Erfahrungen mit anderen Build-Systemen sind wie folgt:

• Bazel: ein riesiger Speicherfresser, unmöglich auf einem Raspberry Pi mit 1 GB Speicher zu laufen, besteht darauf, alle Abhängigkeiten aufzubauen und alles statisch zu verknüpfen
• Autotools: als Entwickler keine Erfahrung, als Benutzer ist das configure Skript sehr praktisch, da es Ihnen alle verfügbaren Optionen anzeigen kann (CMake macht das mit ccmake erst nach dem Ausführen von cmake wenn).

Heute befürworte ich CMake aus einem einzigen Grund: CMake leistet gute Arbeit beim Generieren von Ninja-Dateien anstelle von Makefiles. Ninja kompiliert PaRSEC zwei- bis dreimal schneller als Make -j.

Toll, Ninja konnte Fortran in der Vergangenheit nicht kompilieren, vgl. ninja #1265 , dh bei einigen Distributionen wird dies nicht funktionieren (Debian 9?).

Ich würde definitiv sagen, dass normale Makefiles in diesem Fall einfacher und ausreichend sind.
Wartung von Software in einem HPC-Cluster Ich bin sehr enttäuscht von der Verwendung von Cmake.

1. Entwickler haben es schwer, Standard-Benennungsschemata zu befolgen, was das Erstellen aufgrund des übermäßigen Lesens der Dokumentation erschwert. Jedes Paket führt einige "Optimierungen" von Namen durch, die zu ihren Projekten passen. So endet es in nicht standardmäßigen Benennungsschemata. (ein bisschen wahr für autoconf+, aber hier haben sich die Dinge mehr standardisiert)
2. Wenn in cmake etwas kaputt geht, ist ein cmake-Experte erforderlich, um es zu debuggen.
3. Schwer zu verwendende Konfigurationsdateien (keine make.inc ), dies erzwingt, dass alle Bullild-Optionen zur Build-Zeit in der Befehlszeile angegeben werden.

Auf der anderen Seite macht cmake auch schöne Dinge:

1. Einfachere Windows-Unterstützung
2. Mehr automatische Handhabung von Abhängigkeiten und Einbeziehung von cmake-Dateien für andere Projekte (das ist ein netter Vorteil)

Für das sehr einfache Build-System von LAPACK gibt es meiner Meinung nach jedoch kein Gutes und kein Schlechtes. Das aktuelle Build-System funktioniert seit Jahrzehnten und die Leute sind daran gewöhnt.
Außerdem könnte dies für einen schnellen parallelen Build trivial zum aktuellen Makefile-System hinzugefügt werden ...

Ich habe nicht wirklich eine Präferenz, aber es sollte absolut klar sein, welche Optionen von welchem ​​Build-System unterstützt werden, wenn mehr unterstützt werden ...

Ich habe das Gefühl, dass ich in einer ähnlichen Situation bin wie du @langou .

cmake kenne ich nicht. Ich konnte es nur für dieses Projekt verwenden, weil die gesamte Konfiguration bereits vorhanden war und indem ich die Travis-Konfiguration geöffnet und die ausgeführten Zeilen kopiert und eingefügt habe. Ich glaube nicht, dass es nur daran liegt, dass ich unerfahren bin. Ein Makefile ist etwas weniger magisch und fühlt sich auf niedrigem Niveau an. Das ist etwas, das wahrscheinlich bei der Art von Leuten ankommt, die dazu neigen, an diesem Projekt zu arbeiten.
Wenn ich nur für meinen persönlichen Gebrauch wäre, würde ich gmake weiterhin verwenden, aber dann müssten wir alle Funktionen, die derzeit nur in cmake verfügbar sind, in das Makefile aufnehmen. Vor allem ein Shared-Library-Ziel.

Ich kann jedoch nicht all die netten Funktionen ignorieren, die cmake zu bieten scheint. Letztendlich denke ich, dass entweder cmake oder gmake gut funktionieren. Wir müssen uns nur einen aussuchen.

Ich bin eine externe Stimme, aber als jemand, der bei der Wartung von Lapack in conda-forge hilft, hätte ein Hacky , native Windows-Unterstützung usw.).

Es ist etwas gewöhnungsbedürftig, sich an die CMake-Syntax zu gewöhnen, aber mein Eindruck ist, dass es sich um eine gut gewartete und gut dokumentierte Software handelt, die viele knorrige Build-Probleme erfolgreich gelöst / abstrahiert hat. Ich bin auch an der Verpackung anderer Bibliotheken beteiligt und sehe (subjektiv) immer mehr einen Wechsel zu CMake.

Nur ein weiterer Datenpunkt von außen; In unserer Arbeit, die ziemlich viel C/C++-Building beinhaltet, ziehen wir nach Meson um, nachdem wir zu viel mit CMake zu kämpfen hatten. Die lange Liste der damit verbundenen Probleme ist an anderer Stelle gut dokumentiert, daher überspringe ich diese.

Im SciPy-Projekt werden wir irgendwann auch versuchen, CMake oder Meson zu verwenden, da Python distutils außer Betrieb genommen wird.

Ich bin damit einverstanden, dass die Pflege von drei Build-Systemen zu Inkonsistenzen und/oder zusätzlichem Aufwand für die Betreuer führt. Basierend auf den obigen Kommentaren und meiner Meinung nach hat jeder Benutzer jedoch seine eigene Art, den Code zu erstellen. Insbesondere stimme ich dem Kommentar von

Wir sind Programmierer / Mathematiker / wir machen Algorithmen... Zeit damit zu verbringen, zu verstehen, warum auf dieser Maschine mit dieser Kombination von Compilern und Flags der Code nicht richtig kompiliert wird, das mag niemand. Schlimmer noch, der Versuch herauszufinden, wie man das oder das andere mit CMake oder Autoconf macht, wird Sie die Wand hochfahren :) Wenn Sie mit beiden arbeiten, kann ich Ihnen garantieren, dass Sie sich über beide beschweren werden :) beschweren sich zweimal weniger.

Eine Idee, um das Problem mit mehreren Build-Systemen zu umgehen, ist:

• Erstellen Sie weitere Konfigurationen im CI, damit es alle unterstützten Build-Systeme abdeckt. Auf diese Weise garantieren wir, dass alle Build-Systeme mit den grundlegenden Funktionen funktionieren.
• Präsentieren Sie alle und schlagen Sie die Verwendung eines der Build-Systeme in der README vor. Bsp.: _Wir empfehlen die Verwendung von CMake, wenn Sie gemeinsam genutzte und statische Bibliotheken erstellen müssen, ..._, wie von @martin-frbg, @christoph- conrads und

Soweit ich weiß, hat das Problem mit dem Flag recursive mit den Testroutinen xeigtstz zu tun (siehe https://github.com/Reference-LAPACK/lapack/issues/335# Ausgabekommentar-485021575). Wenn dieses Problem behoben ist, werden wir uns meiner Meinung nach für eines entscheiden

1. füge das Flag zur Standardkonfiguration von CMake hinzu und wo es sonst fehlt, oder
2. Entfernen Sie das Flag aus den make.inc.* Dateien.

Kleines Missverständnis in Bezug auf -frecursive Ich denke, dies ist für das korrekte Funktionieren von Multithread-Code erforderlich und sollte daher im Allgemeinen nicht aus den Build-Dateien entfernt werden. Ein Nebeneffekt ist jedoch, dass lokale Arrays auf den Stack gelegt werden, die im Fall von xeigtstz extrem groß sind. Das Entfernen dieser Option aus (nur) dem TESTING/EIG-Makefile scheint im einfachen Fall zu helfen, aber es scheint beim Kompilieren mit `-fopenmp' impliziert zu sein, so dass dies keine allgemeine Lösung für die ungewöhnlich hohen Stacklimit-Anforderungen dieses Tests ist.

also hier ist das warum.
Ich stimme zu, dass LAPACK eine "einfache" Bibliothek ist - nur ein Make-System zu haben sollte ausreichen, und es war lange genug genug.
Aber aber aber.. es gibt Windows.. und nur wegen Windows mussten wir cmake mitbringen. Ursprünglich haben die Leute von CMake an der Konfiguration gearbeitet, aber jetzt sind wir wohl allein und wie @langou beherrschen wir sie nicht wirklich.
Jetzt verwenden die meisten auf LAPACK basierenden Softwares Cmake und wir wissen aus unserem Benutzerfeedback, dass sie es mögen.

Wenn wir uns also für ein Build-System entscheiden müssen: Das muss Cmake sein... leider für die Gegenwart, aber zum Glück für die Zukunft.

Meine Stimme: Befolge den Rat von @abouteiller und @ @therault und habe nur ein Build-System, also cmake.

Jetzt verwenden die meisten auf LAPACK basierenden Softwares Cmake und wir wissen aus unserem Benutzerfeedback , dass sie es mögen.

Ich habe dieses Problem geöffnet und vorgeschlagen, nur ein Build-System zu verwenden. Meine Annahme war, dass Makefile- und CMake-Kenntnisse ungefähr gleichmäßig verteilt sind. Bitte korrigieren Sie, wenn ich falsch liege, aber mein Eindruck ist, dass dies bei den regulären LAPACK-Mitwirkenden nicht der Fall ist: Makefiles scheinen beliebt zu sein und CMake-Kenntnisse scheinen nicht stark zu sein. Darüber hinaus sind die -frecursive Flags nach zweitägiger Diskussion anscheinend der einzige Unterschied zwischen dem CMake- und dem Makefile-Build und der Tatsache, dass in Travis CI nur CMake verwendet wird. Es macht keinen Sinn, ein Build-System zu erzwingen, das die Benutzer glücklich macht, wenn es die wichtigsten Mitwirkenden vertreibt.

(Mein Urteil darüber, wer regelmäßig Beiträge leistet, basiert auf den ersten fünf Seiten der akzeptierten Pull-Requests.)

Zustimmen.. Übrigens, die rekursiven Flags sind in den Standardkonfigurationen von CMake und Makefile mit #492. Ich denke, wir müssen nur den Makefile-Build in die Travis-CI einbinden.

PR #500 mildert die hier gemeldeten Inkonsistenzen zwischen den Makefile- und CMake-Build-Systemen. Siehe https://github.com/Reference-LAPACK/lapack/pull/500#issuecomment -788164244

Hallo @ilayn. Danke für die Informationen zu Meson / CMake / Makefile. Es ist großartig, Feedback von außen zu haben und Informationen darüber zu erhalten, was andere Projekte tun. Wir können nicht alle drei Systeme unterstützen und bevorzugen derzeit CMake und Makefile, daher werden wir Meson wahrscheinlich außer Betrieb nehmen. Das heißt nicht, dass wir Meson nie verwenden werden, aber im Moment haben wir nicht die Ressourcen, um es zu warten. Das ist meine Meinung. Ich denke, wir werden bald eine PR zur Stilllegung von Meson vorlegen. Julien.