F
@newuser49 sagte in SDL Includes für Vulkan Projekt:
@Finnegan sagte in SDL Includes für Vulkan Projekt:
X:\development\code\vulkan\tmp\VulkanTutorial\libs\SDL\include\SDL3
Bei Angabe von SDL3 am Ende kommt das hier:
E1696 Die Datei "Quelle" kann nicht geöffnet werden: "SDL3/SDL_stdinc.h". vulkan_tutorial X:\development\code\vulkan\tmp\VulkanTutorial\libs\SDL\include\SDL3\SDL.h 32
Was allerdings nicht stimmt da diese Datei existiert, Shift+Rechtsklick -> Pfad kopieren
"X:\development\code\vulkan\tmp\VulkanTutorial\libs\SDL\include\SDL3\SDL.h"
SDL selbst scheint über <SDL3/...> einzubinden und das Tutorial ohne Unterverzeichnis. Ich habe schon viele Bibliotheken mit endlos langen rekursiven Abhängigkeiten in Projekte eingebunden und kann dir sagen, dass sowas echt häufiger vorkommt. Es spricht für deine Einstellung zum Programmieren, wenn dir das nicht gefällt, aber gewöhn dich daran, das ist immer noch besser als das externe Projekt irgendwie anfassen und patchen zu müssen. Bei größeren Projekten wirst du froh um jede Bibliothek sein, die du unmodifiziert in dein eigenes Projekt einbinden kannst - eben weil alle Änderungen, die du machst auch von dir für spätere Versionen weiter gepflegt werden müssen.
Und ja, ich finde es auch etwas unsauber, beide Verzeichnisse in den Includes anzugeben, aber das sind Hacks, die man öfter machen muss, da würd ich mir keinen Kopf drum machen. Du glaubst nicht, was die Build-Systeme verschiedenster Projekte alles für "Hacks" dieser Art enthalten. Ist völlig normal. Wenn ich da an diverse Build-Skripte z.B. von Paketen für irgenwelche Linux-Distributionen denke, dann ist so ein doppeltes Include-Verzeichnis noch ziemlich harmlos. Ich selbst habe auch schon übleres Zeug in Build-Skripten gemacht - den unmodifizierten Quellcode des externen Projekts verwenden zu können ist einfach wichtiger IMHO.
Edit: Ich habe mir mal die CMakeLists.txt des Vulkan Tutorials angesehen, und dort wird SDL2 referenziert, z.B. hier:
# Find SDL2
add_subdirectory(libs/SDL)
Ich halte es für möglich, dass das Include via <SDL3/...> eventuell deshalb von den SDL-Entwicklern eingeführt wurde, damit man beide SDL-Version parallel installiert haben kann, ohne dass die sich gegenseitig in die Quere kommen. Möglicherweise bedeutet #include <SDL.h>, dass man SDL2 und #include <SDL3/SDL.h> dass man SDL3 verwenden möchte.
Du solltest sicherstellen, dass das Tutorial auch mit SDL3 funktioniert und nicht aus irgendeinem Grund SDL2 benötigt. Gut möglich, dass das mit dem doppelten Include einfach so funktioniert, im Zweifelsfall solltest du aber überlegen vielleicht stattdessen SDL2 zu verwenden.