• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

Costum Packages für Msys2 installieren

Roin

Freier Denker

Registriert
22 Juli 2013
Beiträge
581
Hallo Leute,

ich habe mal wieder ein Problem mit Compilern und Compiler-Related Kram.

Ich habe mir vor einiger Zeit man msys2 installiert und mingw64 Kram dafür installiert.
Alles bisher über pacman und die verfügbaren Pakete.

Da ich nun allerdings zwingend cmake 3.11 benötige, um weiter entwickeln zu können, dieses allerdings noch nicht offiziell veröffentlich ist, wollte ich kurzerhand die 3.11-rc4 selber bauen und verwenden.
Wenn ich allerdings nach Anleitung (aus dem MinGW64 Terminal bootstrap inklusive make und make install ausführe, wird der das nach C:/Programme/Cmake/xxxxxx .
Wenn ich allerdings in der Console which cmake aufrufe, erhalte ich: /mingw64/bin/cmake - das ist meiner Meinung nach allerdings die aus dem vorher installierten Package (local/mingw-w64-x86_64-cmake 3.10.2-1).

Wie kann ich nun eigene gebaute Programme damit verwenden? Ich verstehe einfach nicht, was ich anpassen muss, damit ich das ausführen kann.

Normalerweise würde ich eine solche Frage auf stackoverflow stellen, allerdings wird diese dann ziemlich sicher als "Support for xyz not on stackoverflow" markiert... Ich fühle mich in dem Bereich etwas verloren.

Kann mir da jemand einen Tipp geben, wie ich das mache?

Ich habe mir von der cmake.org Seite das Release in einer zip geladen, entpackt, aus dem Terminal (MinGW64) bootstrap, make und make install aufgerufen. Das war offensichtlich nicht ganz richtig. Wie geht es meinen Bedürfnissen entsprechend besser?

LG
 

Brother John

(schein)heilig
Veteran

Registriert
1 Aug. 2013
Beiträge
235
Ich kenne den CMake-Buildprozess nicht, deswegen Vorsicht, Halbwissen! Sieht mir so aus, als müsstest du den Installationsort für *make install* explizit setzen. Du brauchst also ein Äquivalent zu CMakes -DCMAKE_INSTALL_PREFIX; oder bei autotools wär’s der Parameter --prefix für configure. Die CMake-Doku sagt auch ausdrücklich:

You may use the --prefix=<install_prefix> option to specify a custom
installation directory for CMake.
 

Roin

Freier Denker

Registriert
22 Juli 2013
Beiträge
581
  • Thread Starter Thread Starter
  • #3
Dank dir. Ich probiere das mal aus. Vielleicht löst das ja bereits mein Problem.

--- [2018-03-24 12:22 CET] Automatisch zusammengeführter Beitrag ---

[src]
Directory and file names:
--prefix=PREFIX install files in tree rooted at PREFIX
[C:/Program Files/CMake]
--bindir=DIR install binaries in PREFIX/DIR
[bin]
--datadir=DIR install data files in PREFIX/DIR
[share/cmake-3.11]
--docdir=DIR install documentation files in PREFIX/DIR
[doc/cmake-3.11]
--mandir=DIR install man pages files in PREFIX/DIR/manN
[man]
--xdgdatadir=DIR install XDG specific files in PREFIX/DIR
[share]
[/src]
Das muss man anscheinend direkt bei der bootstrap mit aufrufen.
 

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.560
Edit: Okay, das ist irrelevant hier:
Ich glaube du mußt dein "Environment" [kw]env[/kw] anpassen, damit MingW das auf dem "Path" hat für die neue CMake Version bzw. auf deine CMake.

env - zeigt dir alle environment variables die aktuell gesetzt sind, einfach mal in die Konsole (MingW) eingeben.

Vielleicht hilft dir das schon, weil das andere sind "nur" "build parameter" wenn ich richtig deute.



Edit:
Ah okay, du willst ja CMake kompilieren und es wird dir ins falsche Verzeichnis gebaut? - Dann wären die Build Parameter angaben wohl richtig zu verwenden. Ich dachte dein MingW nimmt eine falsche Cmake Version.... :o
 

Roin

Freier Denker

Registriert
22 Juli 2013
Beiträge
581
  • Thread Starter Thread Starter
  • #5
[kw]env[/kw] ist auch interessant.
Mit dem [kw]--prefix[/kw] hat es aber anscheinend geklappt.
Zumindest liefert mir [kw]which cmake[/kw] wieder den gleichen Pfad und ein [kw]cmake --version[/kw] berichtet von Version 3.11-rc4

Mein Projekt, was ich damit kompilieren will, mag zwar immer noch nicht, aber ich bin damit wohl einen Schritt näher.
Er findet nämlich eigentlich jetzt die Boost Libaries von Boost-1.66 aber ein Target (Third libary), was ich zwingend brauche, macht da wohl irgendwas anders und meldet dann, dass Boost-System und Boost-Filesystem nicht gefunden wurde, während es kurz vorher von FindBoost.cmake gefunden wurde...

Da muss ich wohl noch mal ran.
 

Roin

Freier Denker

Registriert
22 Juli 2013
Beiträge
581
  • Thread Starter Thread Starter
  • #7
Ich habe jetzt /mingw64/ genommen - da die entsprechende Shell dann alles mögliche aus dem Verzeichnis nutzt um Wunder zu vollbringen. Vorher hatte er nach C:/Programme/Cmake/ gebaut.
Ist halt für Windows. Ist alles etwas umständlich, wie ich finde. Das müsste eigentlich VIEL VIEL einfacher gehen aber die Leute, die sich damit auskennen wollen das nicht oder können es nicht.
 

theSplit

1998
Veteran Barkeeper

Registriert
3 Aug. 2014
Beiträge
28.560
Ich dachte MingW nutzt die Linux Struktur intern um sich zu organisieren, nur halt im MingW Verzeichniss... da hab ich mich wohl geirrt/falsch gedacht.
Aber vielen Dank für Aufklärung, das sollte auch anderen mit einem ähnlichen Problem helfen. :)

Ich arbeite damit nicht jeden Tag, auch wenn ich es schon genutzt habe, aber trotzdem gut zu wissen. In aller Regel nutze ich aber selbst bereits erstellte Pakete, selbst was kompiliert habe ich damit noch kein Msys2 Paket/Werkzeug. :)
 

Brother John

(schein)heilig
Veteran

Registriert
1 Aug. 2013
Beiträge
235
@Roin
Hat das einen bestimmten Grund, warum du unbedingt MSys auf MinGW oben drauf brauchst? Wenn dir nicht eine Dependency autotools aufs Auge drückt – oder sonst was, wo du unbedingt eine Bash brauchst –, dann funktioniert MinGW auch ganz nativ in der normalen Windows-Shell. OK … oft, jedenfalls. Bei einer Nicht-Microsoft-Toolchain unter Windows musst du immer mit Bastelarbeit rechnen. Ich kenn das aus leidiger Erfahrung.

Ich habe nur sehr wenige (wenn überhaupt) Projekte erlebt, die in ihrem Buildsystem unter Windows sauber MinGW, MinGW+MSys und MS unterstützen. MS ist eh außen vor, weil nicht ABI-kompatibel. Es lohnt sich aber immer, MinGW sowohl mit als auch ohne MSys aufgesetzt zu haben. Manchmal klappts nur mit MSys, manchmal nur ohne. Manchmal nur mit fluchen, googeln und patchen. Du brauchst jedenfalls keine Hemmungen zu haben, manche Dependencies unter MSys zu bauen, manche nativ, und dann wild zu mischen. Hat bei mir immer gut geklappt.

P.S.: Ich merke gerade, dass ich annehme, dass du C- und/oder C++-Software baust. Ist das wirklich so?
 

Roin

Freier Denker

Registriert
22 Juli 2013
Beiträge
581
  • Thread Starter Thread Starter
  • #10
Hat das einen bestimmten Grund, warum du unbedingt MSys auf MinGW oben drauf brauchst?
Ganz einfache Antwort: Ich habe keine Ahnung.
Ich quäle mich schon seit Beginn meiner C++ Erfahrung mit Compilern jeglicher Art und verstehe auch nie ganz genau, was ich da tue - das ist alles ein wenig Voodoo. Cygwin für Cross-Compilation auf einem Pi habe ich mit hängen und würgen ans Rennen gebracht. Wenn es jetzt aber um andere Dinge geht, wie zum Beispiel für Windows bauen oder auf Windows eine Shell zu haben, die ich wie "Linux" verwenden kann und die entsprechend zum Beispiel ctest ausführen kann ist eine Qual.
Normal MinGW ohne alles hat nie geklappt und mich NUR mit Fehlern zugeworfen, die ich häufig nicht mal mit Google finden konnte.
Dann habe ich normal Msys ohne alle versucht - gleicher Mist.
Dann Msys mit MinGW - fast gut aber irgendwie immer noch alles kaputt
Dann Msys2 (da halt gepflegt im Gegensatz zu Msys) und dadrauf noch Windows-Kram (also MinGw und es hat irgendwann mal getan, was es sollte. Es kam am Ende eine exe raus, die in einer Shell ausgeführt wurde und genau das getan hat, was sie sollte und mir auch entsprechenden Output geliefert.
Nun ging es zwischenzeitlich nicht mehr, da Boost ja in den Package-Managern direkt geupdated wird, bevor beispielsweise cmake oder so es unterstützt - Downgrade ist erstaunlich schwierig und das Upgrade auch etwas umständlicher als gewollt, wenn Pacman da nichts in der Datenbank für findet, was beispielsweise gerade mit cmake und der 3.11 der Fall ist.

Wieso gibt es nicht eine exe Beispielsweise, die einem beim Start ein paar Fragen stellt, was man tun möchte und dann alles notwendige Zusammensucht und installiert? Und nachinstallieren dann mit sowas wie pacman bzw linux-style aptitue usw. Auch mit Paketen, die nicht in der Datenbank vorliegen...

Ich verstehe nicht, wieso noch kein kundiger sowas erstellt hat - ist das ein so krasses Geheimnis oder schafft es einfach keiner?

Wenn es um diesen ganzer Compiler-Kram für komplexere Programme geht, bin ich unter Linux schon verloren. Aber auf Windows für alle anderen Plattformen entwickeln... Ich brauche ja da bereits Tage, bis ich ein Hello World für die gängigen Plattformen rausbekomme, wenn ich das überhaupt schaffe.

Ich merke gerade, dass ich annehme, dass du C- und/oder C++-Software baust. Ist das wirklich so?
Also vorweg: Ja, es geht bei mir um C++-Software - vielleicht irgendwann noch was anderes aber erstmal speziell C++
 

Brother John

(schein)heilig
Veteran

Registriert
1 Aug. 2013
Beiträge
235
Buildsysteme und Paketmanagement in der C++-Welt … *seufz* … Es gibt genug Plattformen, wo das klappt: Python mit pip, Rust mit Cargo, Javascript mit npm, Go mit … weiß den Namen nicht. Alle (Fast? Bei npm bin ich mir nicht sicher.) haben sie gemeinsam, dass die Institution, die sich um die Sprache/Standardlib kümmert, auch um Build/Paketmgmt kümmert. Das ist ein Unterschied zu C++. Bis zum ersten ISO-Standard (1998) gabs noch nicht mal die eine *Sprache*. Jeder Compilerhersteller hat sein eigenes Süppchen gekocht. Jetzt gibts das ISO-Komittee, aber das steht auf dem Standpunkt, dass Buildsysteme nicht wirklich und Paketmanager schon gar nicht in ihren Scope fallen. Kann ich zumindest zum Teil auch nachvollziehen. Also dümpelt das Thema vor sich hin. Obwohl gerade in den letzten 1–2 Jahren die Stimmen lauter werden, dass sie Situation echt Kacke ist und sich ändern muss. Ich bin verhalten optimistisch für die nächsten Jahre, aber schau mer mal.

So, Rant erledigt. :D Lass uns was praktisches machen.

Wie startest du denn dein MSys? Das sollte über die *mingw64_shell.bat* passieren (oder die mit 32, wenn du 32bit-Binaries baust). Jedenfalls nicht über die *msys2_shell.bat*

Aus deinem letzten Post ist mir nicht ganz klar, ob Boost wieder geht … Wenn einmal Boost gefunden wird und einmal nicht, spricht das dafür, dass das CMake-System vom Nicht-Finder kaputt ist. Meistens ist die Auto-Finderei auch unnötig, weil alle Libs sowieso in den System-Standardpfaden liegen, wo sie eh gefunden werden. Zwei Möglichkeiten: Bei manchen Projekten kann man für Dependencies explizit Pfade angeben. Mit ein bisschen Glück stehts in der Doku. Ansonsten gewöhnt dich daran, CMakeLists.txt zu lesen. Kommst du längerfristig eh nicht dran vorbei. Zweite Möglichkeit: die (unnötige) Boost-Detection aus dem CMake-System rauspatchen. Da sind wir dann schon mitten im CMake-Code. :)

Oder in ne ganz andere Richtung gedacht: Wäre cross-compiling von Linux aus ne Alternative? Das würde mich direkt auch interessieren, das zum Laufen zu kriegen. Windows-Software bauen ohne umbooten oder VM hochfahren, hätte schon was.
 

Roin

Freier Denker

Registriert
22 Juli 2013
Beiträge
581
  • Thread Starter Thread Starter
  • #12
Ich bin verhalten optimistisch für die nächsten Jahre, aber schau mer mal.
Naja da hoffen wir einfach mal...

Wie startest du denn dein MSys? Das sollte über die *mingw64_shell.bat* passieren
Genau die starte ich auch.
Ich versuche häufig Software, die später auf einem Linux-basierten System laufen soll, einfach auf dem Rechner, der gerade in der Nähe ist zu bauen und auch direkt zu testen. Speziell die Unittests interessieren mich dabei, da ich besonders die Test-Coverage entwickeln möchte. Dann muss ich häufig einfach die Software auf zum Beispiel Windows laufen lassen können - einfach um Zeit zu sparen, da es dann schneller laufen würde. Die Test-Hardware, die ich zur Verfügung habe hat nicht sonderlich viel Leistung, daher nutze ich auch ganz gerne mal einen privaten Rechner zum kompilieren. Wenn es nur darum geht das Projekt für die Testhardware Crosscompilieren zu können, geht das mit Cygwin meistens auch ganz gut - da kann ich aber nicht einfach so die Tests laufen lassen, was mein Hauptproblem war / ist.

Boost 1.66 wird mit cmake 3.11 wieder unterstützt. Die Third-Libary, die ich da nutze, macht da irgendwelche Sondersachen, auf unfassbar viele Cmake-Dateien aufgeteilt, sodass ich noch nicht herausgefunden habe, wo das Boost-Gedöns rumsteht. Die findet die nämlich nicht. Sonst wird Boost gefunden und läuft auch wieder.

Wäre cross-compiling von Linux aus ne Alternative? Das würde mich direkt auch interessieren, das zum Laufen zu kriegen. Windows-Software bauen ohne umbooten oder VM hochfahren, hätte schon was.
Ich würde ganz gerne von Windows für alles andere bauen können, mit einem zusätzlichen Parameter wie "windows32" oder "arm" oder "linux" oder so. Ebenso wäre es für mich allerdings auch interessant genau das gleiche von einem Linux-System aus zu machen.

Problem dabei: Ich kann C++ programmieren. Ich kann CMakeLists.txt mehr oder minder gut lesen und kleine Anpassungen machen; die Befehle kenne ich aber noch nicht ausreichend auswendig. Normale Makefiles und normale Compiler-Aufrufe über die Shell sind ein Graus. Joar.
Zudem: Ich bin relativ neu in der Nutzung von Linux-Systemen. Bedeutet also, dass ich mehr oder minder gut alles finde, was ich brauche und auch Pakete installieren, deinstallieren usw kann. In den Systemeinstellungen rumfuschen ist aber noch nicht so meins. In ein paar Wochen werde ich mir aber sowieso noch mehrere Betriebssysteme aufsetzen oder entsprechende VMs einrichten. Da ist mein Rechner aktuell einfach etwas knapp auf der Brust, was den benötigten SSD-Speicher angeht. :D
 

Rakorium-M

NGBler

Registriert
14 Juli 2013
Beiträge
413
Alternativer Weg:
Mal überlegt WSL (Windows Subsystem für Linux) zu nutzen? Damit laufen im Prinzip native Linux-Programme (inklusive Paketmanager) auf Windows. Manche IDEs (zum Beispiel CLion) unterstützen das auch schon, dann merkst du von dem Linux-Unterbau nicht mehr viel.
 

Roin

Freier Denker

Registriert
22 Juli 2013
Beiträge
581
  • Thread Starter Thread Starter
  • #14
@Rakorium-M: Guter Tipp: Kannte ich noch nicht. Ich schau mir das mal in der nächsten Woche an.
 
Oben