Autor Thema: AtariX => MagicOnLinux  (Gelesen 44395 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Offline don_apple

  • Benutzer
  • Beiträge: 56
Re: AtariX => MagicOnLinux
« Antwort #500 am: Gestern um 20:53:08 »
@Lukas Frank Sehr komische Fehlermeldungen  ???

Auf meinem Ubuntu MacBookPro hat es ja geklappt, vielleicht liegen meine Probleme daran das ich kein macOS 15 Sequoia auf meinem M4 MacMini habe sondern ein 26 Tahoe ...?
Nein, glaube ich nicht.

Bei deinem letzten Versuch hast du anscheinend das cmake nicht aus dem "build" Verzeichnis gestartet:
Franks-MacMini:magiclinux frank$ cmake -G Xcode
Und da fehlen die 2 Punkte ("..") am Ende des cmake Kommandos. Die sind wichtig!

Lies dir nochmal https://gitlab.com/AndreasK/magiclinux/-/blob/main/MACOS.txt?ref_type=heads genau durch und verwende die Kommandos genauso wie sie da angeben sind.

Oder verwende das build_macos.sh Shell-Script das ich bereits erwähnt hatte.
« Letzte Änderung: Gestern um 20:55:17 von don_apple »

Offline ragnar76

  • Moderator
  • *****
  • Beiträge: 742
Re: AtariX => MagicOnLinux
« Antwort #501 am: Gestern um 22:00:06 »
@Lukas Frank Sehr komische Fehlermeldungen  ???

Auf meinem Ubuntu MacBookPro hat es ja geklappt, vielleicht liegen meine Probleme daran das ich kein macOS 15 Sequoia auf meinem M4 MacMini habe sondern ein 26 Tahoe ...?
Ich hab ein MacBook M2 pro mit 26.4.1, das klappt also

Offline Lukas Frank

  • Benutzer
  • Beiträge: 14.674
  • fancy Atari Musik anDA Dance "Agare Hinu Harukana"
Re: AtariX => MagicOnLinux
« Antwort #502 am: Heute um 08:27:24 »
Habe den build direkt aus Xcode versucht und scheinbar klappt das aber die Programmdatei wird nicht erzeugt ...?

Offline Lukas Frank

  • Benutzer
  • Beiträge: 14.674
  • fancy Atari Musik anDA Dance "Agare Hinu Harukana"
Re: AtariX => MagicOnLinux
« Antwort #503 am: Heute um 09:34:16 »
Soweit bin ich jetzt ...


Franks-MacMini:~ frank$ cd magiclinux
Franks-MacMini:magiclinux frank$ mkdir build
Franks-MacMini:magiclinux frank$ cd build
Franks-MacMini:build frank$ cmake -G Xcode ..
-- The C compiler identification is AppleClang 21.0.0.21000099
-- The CXX compiler identification is AppleClang 21.0.0.21000099
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PkgConfig: /opt/homebrew/bin/pkg-config (found version "2.5.1")
-- Checking for module 'sdl2'
--   Found sdl2, version 2.32.10
-- Checking for module 'sdl2_mixer'
--   Found sdl2_mixer, version 2.8.1
-- Configuring done (5.9s)
-- Generating done (0.0s)
-- Build files have been written to: /Users/frank/magiclinux/build
Franks-MacMini:build frank$

Offline Lukas Frank

  • Benutzer
  • Beiträge: 14.674
  • fancy Atari Musik anDA Dance "Agare Hinu Harukana"
Re: AtariX => MagicOnLinux
« Antwort #504 am: Heute um 10:45:34 »
xcode ...

Schaffe es aber nicht das Programm zu erzeugen. Weiß auch nicht was und wie ich da was machen soll? Bin zu blöd.
« Letzte Änderung: Heute um 11:46:47 von Lukas Frank »

Offline AndreasKromke

  • Benutzer
  • Beiträge: 202
Re: AtariX => MagicOnLinux
« Antwort #505 am: Heute um 11:02:58 »
Etwas Grundlagen:

Früher hat man ein Projekt ein "Makefile" geschrieben. Das ist eine Textdatei. Sie enthält eine Liste aller Quelltextdateien, die übersetzt werden müssen, und die Anweisungen, wie sie übersetzt werden müssen. Außerdem konnte man noch Abhängigkeiten angeben, damit bei Änderung von Datei A automatisch die Dateien X und Y neu übersetzt werden und der Linker das Programm neu bindet.

Die Datei hieß i.a. "Makefile", und man hat im selben Verzeichnis das Kommando "make" aufgerufen. Das kann man heute noch so machen und ist für kleinere Programme auch legitim.

Für größere Programme schreibt man heute das "Makefile" nicht mehr selbst, sondern benutzt einen Makefile-Generator. Davon gibt es mehrere, und cmake ist der weitestverbreitete. Ein Vorteil von cmake ist, daß man unterschiedliche Betriebssysteme und Compiler berücksichtigen kann. So erzeugt cmake je nach Umgebung ein angepaßtes "Makefile" mit entsprechenden Compiler-Einstellungen.

Die zentrale Steuerdatei für cmake ist i.a. "CMakeLists.txt". Hieraus macht cmake dann das Makefile. Damit man sein Projektverzeichnis nicht mit Kompilaten vollschreibt (man möchte Quelltexte trennen von den Dateien, die temporär erzeugt werden), verwendet man ein "build"-Verzeichnis. Nach Konvention heißt es "build", der Name ist aber egal. Fast alle modernen Programme werden so erzeugt:

  • Ein "build"-Verzeichnis wird erzeugt und betreten. Hier landet der ganze temporäre Müll, aber auch das fertige Programm.
  • Man ruft "cmake .." auf, dabei ist ".." der Parameter, mit Leerzeidchen getrennt, der dem cmake sagt wo es die Datei CMakeLists.txt suchen soll.
  • Das cmake rattert rum, macht dies, das, Ananas und erzeugt schließlich ein "Makefile".
  • Wie oben beschrieben, kann man jetzt per "make" den Bau-Prozeß starten.
  • Abschließend kann man den "build"-Ordner wieder verlassen.

Das cmake sollte in das "Makefile" einen Mechanismus einbauen, der erkennt, wenn das "Makefile" selbst neu erzeugt werden muß, also von der Theorie her braucht man cmake fürderhin nicht mehr zu starten, sondern immer nur make, es sei denn es geht etwas schief. Wenn man Quelltextdateien hinzufügt oder entfernt, könnte das nötig sein.

Abschließend: Man kann dem "cmake" auch Parameter mitgeben, um die Generierung des Makefile zu beeinflussen, z.B. wenn man einen "debug build" will. Warum man das nicht später beim make festlegt? Keine Ahnung, bin kein cmake-Spezialist ...
« Letzte Änderung: Heute um 11:05:11 von AndreasKromke »