CLion GLFW library einbinden?
Ich schaffe es einfach nicht meine library einzubinden...
Hier ist die ordner struktur:
Bis jetzt kommt noch kein Fehler.
Und ich nehme einfach den tutorial Code auf der website von glfw.
Oben steht dann noch
#include "Libraries/include/GLFW/glfw3.h"
drin. (Nicht Rot makiert)
Und wenn ich das jetzt laufen lasse kommt mehrmals
undefined reference to `__imp_glfwInit' oder undefined reference to `__imp_glfwCreateWindow' und halt so 10 stück davon.
Ich sehe irgendwie ich muss #define GLFW_DLL über den code schreiben (hab ich auch gemacht)
Aber dann muss ich glaube ich auchnoch
target_link_libraries(Tesst Libraries/lib/lib-vc2022 glfw)
So etwas machen. und wenn ich jetzt auf reload changes gehe sagt er mir
CMake Error at CMakeLists.txt:7 (target_link_libraries):
Cannot specify link libraries for target "Tesst" which is not built by this
project.
Was mache ich falsch? Muss ich irgendwie die bin von GLEW oder wie das heist haben?
1 Antwort
Installier dir doch glfw auf deinem System und lass CMake die Bibliotheken finden:
https://www.glfw.org/docs/3.3/build_guide.html#build_link_cmake_package
Dein Include dürfte dann einfach nur
#include <GLFW/glfw3.h>
Hat nicht geklappt.
Welche Fehlermeldung?
Hast du GLFW auf deinem System installiert und befindet sich passende Environment-Variablen im PATH?
Also bei dem add_subdir sagt er mir direct wenn ich \ eingeben einen Fehler
Versuch es mit '/' statt '\'.
Außerdem würde ich wenn dann die Library zum Projekt hinzufügen und den Pfad relativ angeben.
Was heist denn installiert? Was muss ich denn installieren? Ich habe nur die zip entpackt!
Kannst du mir vielleicht einfach sagen was hier jetzt noch passieren muss?
Schau mal, ob du eine findglfw.cmake Datei oder etwas in der Art hast:
https://cmake.org/cmake/help/latest/command/find_package.html
Wenn ja, schau dir mal den derzeitigen CMAKE_MODULE_PATH an und setz den entsprechend, so dass die Datei gefunden werden kann.
Wenn das nicht klappt muss ich mich da einmal genauer reindenken.
Ich verstehe nicht ganz was die da schreiben... Und von wo bis wo ich lesen muss Kannst du mir nicht einfach sagen was ich schreiben muss? 😅 Du hast ja die datein die ich habe da kannst du doch wissen was ich schreiben muss oder? (keine ahnung warum das jetzt dick geschrieben ist)
Schau mal hier:
https://stackoverflow.com/questions/54834826/cannot-find-package-glfw-using-cmake
Hol dir die verlinkte Datei von
https://github.com/JoeyDeVries/LearnOpenGL/blob/master/cmake/modules/FindGLFW3.cmake
und packe sie an die passende Stelle.
Dann fügst du in deiner CMakeList.txt folgendes hinzu:
list(APPEND CMAKE_MODULE_PATH "${PROJECT_SOURCE_DIR}/cmake")
Deine Bibliothek installierst du unter
"${CMAKE_SOURCE_DIR}/includes"
Das Script ist nicht optimal, aber sollte tun, was du willst.
Ja klappt garnicht... Vermutlich muss ich phade angleichen aber finde keine richtigen. er sagt sogar schon "By not providing "Findglfw3.cmake" :( Ich verstehe das garnicht welche pfade muss ich anpoassen und wo muss ich die datei reinlegen
Wie sieht deine Verzeichnisstruktur aus? Wo hast du das Find.cmake hingepackt?
Nutz mal
message(STATUS <message>);
um dir die relevanten Variable ausprinten zu lassen (z.B. ${PROJECT_SOURCE_DIR}).
Hab oben geschrieben hab es in die project folde probiert und in CMakeFiles wo es auch sinn macht
Project:ourcce_dir ist in C:/Users/alpha/OneDrive/Desktop/Tesst
Und in
C:/Users/alpha/OneDrive/Desktop/Tesst/cmake
ligt die Find.cmake?
Und du hast
list(APPEND CMAKE_MODULE_PATH "${PROJECT_SOURCE_DIR}/cmake")
noch vor dem find_package stehen?
https://workupload.com/file/haK6FvLGSfs
Ich habe auch .cmake statt cmake versucht
Schaust du eig auf die bilder?
Soweit ich das sehe ist der Find.cmake-File nicht unter "/cmake", sondern unter "/cmake/api", evtl. macht das Probleme?
Ansonsten schau mal ob du in den Find.cmake-File eine Ausgabe packen kannst und was die dir liefert.
Ich schaue mir das dann morgen weiter an.
Ist nicht in api wenn man genau hinschaut.
Und
message(STATUS Find.cmake-File)
gibt einfach nur -- Find.cmake-File aus es macht auch erst ab der zeile 8 also bei find_package() probleme
Ist ja klar, dass du da nur die Ausgabe bekommst.
Ich meine, du sollst mal den Findglfw.cmake editieren und da ein message reinpacken und schauen, ob du eine Ausgabe erhälst. Wenn nicht, dann wird der File nicht ausgeführt, wenn doch, dann wird er ausgeführt.
Je nachdem, was der Fall ist, müsste man an einer anderen Stelle weiter suchen.
Ist nicht in api wenn man genau hinschaut.
Ich habe mehrmals genau hingeschaut. Das Icon des Files ist auf selber Höhe wie "v1", liegt somit in api, sofern die Anzeige nicht kaputt ist.
Also das ist ein ausschnitt aus dem Bild und ich finde hier sieht man es 😅 ist jetzt nicht böse gemeint (wieder dick keine ahnung warum)
Wenn ich zuhause bin versuch ich das mal in die cmake file zu schreiben.
Aber muss ich nicht wirklich irgendeinen pfad anpassen? Der weiß doch garnicht wo ich die librarie hingelegt habe?
Aber muss ich nicht wirklich irgendeinen pfad anpassen? Der weiß doch garnicht wo ich die librarie hingelegt habe?
Deshalb sagte ich ja, du sollst die in einen bestimmten ordner packen. Aber ja, im ZWeifelsfalle passt du die Pfade in Find.cmake an, portabler wäre es aber wohl, die Dateien selbst in das passende Directory zu packen.
Ja das problem ist ich weis nicht wo die das hatten und ich weis nicht welche pfade in anpassen muss... wo ist das alles
"/usr/include"
"/usr/local/include"
"${CMAKE_SOURCE_DIR}/includes"
"C:/Program Files (x86)/glm" )
und muss ich dieüberhaubt anpassen oder andere
Du packst die Header am besten in/unter
"${CMAKE_SOURCE_DIR}/includes"
und die Libs in/unter
"${CMAKE_SOURCE_DIR}/lib"
Jetzt habe ich den include ordner aus der librarie in Tesst/ gepackt also sind die .h jetzt in Tesst/include/GLFW/ und die libraries also sowas wie lib-vc2022 sind jetzt in Tesst/lib/.
Die FindgGLFW3.cmake datei ist in Tesst/.cmake/
Der inhalt ist:
cmake_minimum_required(VERSION 3.23)
project(Tesst)
set(SOURCE_FILES main.cpp) # welche Dateien kompiliert werden sollen
list(APPEND CMAKE_MODULE_PATH "${PROJECT_SOURCE_DIR}/cmake")
find_package(cmake REQUIRED)
add_executable(Tesst main.cpp)
Vielleicht hilft ja auch der ganze Fehler:
CMake Error at CMakeLists.txt:8 (find_package):
By not providing "Findcmake.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "cmake", but
CMake did not find one.
Could not find a package configuration file provided by "cmake" with any of
the following names:
cmakeConfig.cmake
cmake-config.cmake
Add the installation prefix of "cmake" to CMAKE_PREFIX_PATH or set
"cmake_DIR" to a directory containing one of the above files. If "cmake"
provides a separate development package or SDK, be sure it has been
installed.
Offenbar braucht es noch einen anderen File:
Ich habe das glaube ich auch schon einmal gemacht, aber ich finde das leider gerade nicht mehr.
Ich würde folgende Files ausprobieren:
https://github.com/glfw/glfw/tree/master/CMake
Sieht mir aber falsch aus, ist mir aber gerade zu spät das nachzuprüfen.
Alle Projekte, die auf meiner Platte liegen und glfw verwenden bauen sich das offenbar direkt aus den Source.
Beispiel:
https://github.com/KhronosGroup/Vulkan-Hpp
Dann ist das Includen aber evtl. komplizierter, evtl. finden sich noch andere Beispiele online.
Eines der Projekte hat glfw im ordner "/external/glfw" und baut das wiefolgt in der CMakeLists.txt:
##############################################################################
# GLFW
##############################################################################
set(GLFW_SOURCE_DIR "external/glfw")
set(BUILD_SHARED_LIBS OFF CACHE BOOL "")
set(GLFW_BUILD_EXAMPLES OFF CACHE BOOL "")
set(GLFW_BUILD_TESTS OFF CACHE BOOL "")
set(GLFW_BUILD_DOCS OFF CACHE BOOL "")
set(GLFW_INSTALL OFF CACHE BOOL "")
add_subdirectory(external/glfw)
include_directories(external/glfw/include
external/glfw/deps)
Include geht dann offenbar mit
#include <GLFW/glfw3.h>
Ich verstehe garnichts mehr... Warum haben die in YT videos nicht diese Probleme? Wie hast du es denn damals gemacht? Muss doch bei mir genau so klappen
Ich musste das nie selber Includen, das haben die APIs immer selber gemacht glaube ich.
Aber habe dir hier geschrieben, wie die das offenbar gemacht haben.
Im YouTube-Video haben die vermutlich irgendwie GLFW bereits so installiert (mit einem Package-Manager unter Linux zum Beispiel).
Wenn ich das so eingebe und die include und lib-vc2022 und das andere zeug in Tesst/external mache und den code von der nachricht von dir in die CMakeFile eingebe kommt
CMake Error at CMakeLists.txt:14 (add_subdirectory):
The source directory
C:/Users/alpha/OneDrive/Desktop/Tesst/external/glfw
does not contain a CMakeLists.txt file.
Lösch die Binaries, lad dir stattdessen die ganze Library als Source runter und packe die in "/external":
Du meinst das Quellpacket bei https://www.glfw.org/download.html ?
Okay keine errors mehr! Aber es gibt kein #include <GL... da kommt schion nichts mehr und bei dem ganzem statement sagt er halt gibt es nicht. Hier die ordnung:
ber es gibt kein #include <GL... da kommt schion nichts mehr und bei dem ganzem statement sagt er halt gibt es nicht
Schreib mal hin und schau, ob es compiliert. *daumendrück*
FAILED: Tesst.exe
cmd.exe /C "cd . && C:\msys64\mingw64\bin\c++.exe -g CMakeFiles/Tesst.dir/main.cpp.obj -o Tesst.exe -Wl,--out-implib,libTesst.dll.a -Wl,--major-image-version,0,--minor-image-version,0 -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ."
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/Tesst.dir/main.cpp.obj: in function `main':
C:\Users\alpha\OneDrive\Desktop\Tesst/main.cpp:76: undefined reference to `glfwInit'
collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
:(
Aber rot ist es nicht (also im code fenster)
Das wichtigste:
C:\Users\alpha\OneDrive\Desktop\Tesst/main.cpp:76: undefined reference to `glfwInit'
Ah gut die Includes findet er, jetzt muss er nur noch dei Bibliothek mitlinken.
Ich glaube ein
target_link_libraries(<target> ${GLFW_LIBRARIES})
fehlt noch irgendwo.
Was kommt als target rein? Tesst geht nicht 😅
https://cmake.org/cmake/help/latest/command/target_link_libraries.html
The named
<target>
must have been created by a command such asadd_executable()
oradd_library()
Du willst vermutlich irgendwo "add_executable" verwenden.
Vermutlich dann einfach "Tesst.exe" statt "Tesst".
CMake Error at CMakeLists.txt:19 (target_link_libraries):
Cannot specify link libraries for target "main.cpp" which is not built by
this project.
ninja: error: rebuilding 'build.ninja': subcommand failed
-- Configuring incomplete, errors occurred!
See also "C:/Users/alpha/OneDrive/Desktop/Tesst/CMakeFiles/CMakeOutput.log".
FAILED: build.ninja
Die exe ist main.exe
Dann nimmst du "main.exe" oder "main.cpp".
Allerdings steht oben in der fehlermeldung "Tesst.exe" als Output.
Also ich bin mir schon sicher das es die main.exe ist ist das nicht das default bei CLion?
set(SOURCE_FILES main.cpp)
add_executable(Tesst main.cpp)
Und ich habe mani.exe und main.cpp versucht
Und eine Tesst.exe gibt es nur in cmake-build-debug und wenn ich das eingebekommt auch not build by this project
Okay wenn ich n ach add_exe das mache sagt er bei Tesst keinen Fehler. Allerdings findet er glfwInit immernoch nicht.
Also ich bin mir schon sicher das es die main.exe ist ist das nicht das default bei CLion?
Keine Ahnung, was der Default ist. bNach deinem Command ist es aber auch "Tesst.exe".
Allerdings findet er glfwInit immernoch nicht.
Kannst du noch einmal die ganze fehlermeldung posten. Der Befehl, der oben steht, ist relevant dabei, insbesondere die Library-Flags dahinter.
Okay hier ist es jetzt:
"C:\Program Files\JetBrains\CLion 2022.2.4\bin\cmake\win\bin\cmake.exe" --build C:\Users\alpha\OneDrive\Desktop\Tesst --target Tesst -j 9
[1/1] Linking CXX executable Tesst.exe
FAILED: Tesst.exe
cmd.exe /C "cd . && C:\msys64\mingw64\bin\c++.exe -g CMakeFiles/Tesst.dir/main.cpp.obj -o Tesst.exe -Wl,--out-implib,libTesst.dll.a -Wl,--major-image-version,0,--minor-image-version,0 external/glfw/src/libglfw3.a -lopengl32 -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ."
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/Tesst.dir/main.cpp.obj: in function `main':
C:\Users\alpha\OneDrive\Desktop\Tesst/main.cpp:77: undefined reference to `__imp_glfwInit'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\alpha\OneDrive\Desktop\Tesst/main.cpp:79: undefined reference to `__imp_glfwTerminate'
collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
Also er versucht auf jeden Fall irgendwie glfw mitzulinken.
Ersteinmal generell eine Sache: Bei mir habe ich nie etwas auf Windows sinnvoll mit gcc bauen können, das allein kann schon Probleme machen.
Das scheint hier auch ein Problem zu sein:
https://stackoverflow.com/questions/22623087/undefined-reference-errors-when-linking-glfw-on-mingw
Offenbar muss man es irgendwie hinbekommen, dass gcc das Ding nicht ".a" nennt, sondern ".dll".
Versuch mal irgendwo folgendes zu setzen:
https://cmake.org/cmake/help/v3.0/variable/CMAKE_STATIC_LIBRARY_SUFFIX.html
https://cmake.org/cmake/help/v3.0/variable/CMAKE_SHARED_LIBRARY_SUFFIX.html
Jeweils auf entsprechend ".dll" und ".lib".
Ich verstehe das nicht... Es gibt in CMakeLists
CMAKE_STATIC_LIBRARY
Und ich habe gestern das ganze project durchgeschaut und nicht eine .a file gefunden
Das ist eine Variable, die gesetzt werden soll:
set(CMAKE_STATIC_LIBRARY ".lib");
set(CMAKE_SHARED_LIBRARY ".dll");
Die ".a"-Files baut CMake als Zwischenprodukt selbst (und findet sie dann offenbar nicht mehr).
Ich hab das jetzt eingegeben aber er sagt immernco das selbe. Ich habe jetzt übrigens eine a datei gefunden.
Aber es ist die iibglfw3.a
Und wenn ich sie entferne wie es da steht in deinem Link passiert auch nichts.
Auch noch dasselbe Command in der Fehlermeldung?
Setz mal folgende Flag:
GLFW_DLL
Mittels:
set(GLFW_DLL ON CACHE BOOL "")
Oder evtl. auch ohne den Teil hinter "CACHE", keine Ahnung, was der bewirkt.
Nein... nichts :( hier die ganze CMakeLists.txt vielleicht ist ja irgendwas falsch
cmake_minimum_required(VERSION 3.23)
project(Tesst)
set(SOURCE_FILES main.cpp) # welche Dateien kompiliert werden sollen
set(GLFW_SOURCE_DIR "external/glfw")
set(BUILD_SHARED_LIBS OFF CACHE BOOL "")
set(GLFW_BUILD_EXAMPLES OFF CACHE BOOL "")
set(GLFW_BUILD_TESTS OFF CACHE BOOL "")
set(GLFW_BUILD_DOCS OFF CACHE BOOL "")
set(GLFW_INSTALL OFF CACHE BOOL "")
set(GLFW_DLL ON CACHE BOOL "")
set(CMAKE_STATIC_LIBRARY ".lib")
set(CMAKE_SHARED_LIBRARY ".dll")
add_subdirectory(external/glfw)
include_directories(external/glfw/include external/glfw/deps)
add_executable(Tesst main.cpp)
target_link_libraries(Tesst glfw)
Wie gesagt immernoch das genau gleiche:
FAILED: Tesst.exe
cmd.exe /C "cd . && C:\msys64\mingw64\bin\c++.exe -g CMakeFiles/Tesst.dir/main.cpp.obj -o Tesst.exe -Wl,--out-implib,libTesst.dll.a -Wl,--major-image-version,0,--minor-image-version,0 external/glfw/src/libglfw3.a -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ."
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/Tesst.dir/main.cpp.obj: in function `main':
C:\Users\alpha\OneDrive\Desktop\Tesst/main.cpp:77: undefined reference to `__imp_glfwInit'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\alpha\OneDrive\Desktop\Tesst/main.cpp:79: undefined reference to `__imp_glfwTerminate'
collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
Lösch mal das Directory, das CMake erstellt und den Cache-File und versuch es noch einmal. Aus irgendwelchen Gründen nimmt er weiterhin die statische Library.
Evtl. kannst du auch mal folgendes ausschalten und schauen, ob es dann geht:
set(BUILD_SHARED_LIBS OFF CACHE BOOL "")
Evtl. kann es aber auch sein, dass du deinen "target_link_library" Call umändern musst:
target_link_libraries(myapp glfw ${GLFW_LIBRARIES})
Hier steht auch noch mehr dazu, da kann man dann noch etwas rumprobieren:
Ja also dieser ordner ist leer also war er schon vorher
Lösch ihn trotzdem mit. Der Cache ist das wichtigere, ich will nur, das CMake noch einmal neu baut.
Habe jetzt das
#set(BUILD_SHARED_LIBS OFF CACHE BOOL "")
auskommentiert und das targetlinklibr zu
target_link_libraries(Tesst glfw ${GLFW_LIBRARIES})
Und den CMakeFiles gelöscht aber passiert immernoch das Gleiche.
Auch noch mit dem selbem Command in der Fehlermeldung?
Dann ändere mal zu
target_link_libraries(myapp -lglfw3)
Ah jetzt kommt etwas anderes!
"C:\Program Files\JetBrains\CLion 2022.2.4\bin\cmake\win\bin\cmake.exe" --build C:\Users\alpha\OneDrive\Desktop\Tesst --target Tesst -j 9
[1/1] Linking CXX executable Tesst.exe
FAILED: Tesst.exe
cmd.exe /C "cd . && C:\msys64\mingw64\bin\c++.exe -g CMakeFiles/Tesst.dir/main.cpp.obj -o Tesst.exe -Wl,--out-implib,libTesst.dll.a -Wl,--major-image-version,0,--minor-image-version,0 -lglfw3 -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ."
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lglfw3: No such file or directory
collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
Mach mal
#set(BUILD_SHARED_LIBS ON CACHE BOOL "")
oder versuch es mit
target_link_libraries(myapp -lglfw)
Ja er sagt immernoch cannot find -lglfw: No such file or directory
Hm, okay. Dann versuch es mal mit:
target_link_libraries(Tesst /external/glfw/glfwdll.lib)
Oder so ähnlich, sollte halt der Paf zu deiner Library sein.
Hier nochmal die ordner vielleicht ist da was falsch
Die Includes funktionieren ja, also wird es denke ich nicht an der ordnerstruktur liegen.
Darum hab ich ja gemeint das man es manchmal nicht siht
Aber du siehst ja in external/glfw/sind nur ordner und keine lib dtei
Ah und da ich es erst jetzt sehe:
set(CMAKE_STATIC_LIBRARY ".lib")
set(CMAKE_SHARED_LIBRARY ".dll")
zu
set(CMAKE_STATIC_LIBRARY_SUFFIX ".lib")
set(CMAKE_SHARED_LIBRARY_SUFFIX ".dll")
vielleicht geht es dann.
Aber du siehst ja in external/glfw/sind nur ordner und keine lib dtei
Deshalb musst du selber schauen, wo die liegt.
Dann heißt die halt anders, musst du manuell schauen. Wahrscheinlich unter "external/glfw/src".
Also bei mir gibt es einfach keine lib und keine dll datei mehr...
Hier ist das external package vielleicht findest du ja etwas?
https://drive.google.com/file/d/1ELQT62Y4fhR3HRPHC0mcTwiOfJXF0qGb/view?usp=share_link
Hm, okay. Naja, schau mal, ob es eine ".so"-Datei gibt oder nehm die ".a"-Datei.
Auf das Google-Dingens kann ich nicht zugreifen.
Jetzt sollte es gehen
https://drive.google.com/file/d/1ELQT62Y4fhR3HRPHC0mcTwiOfJXF0qGb/view?usp=share_link
eine a datei gibt es. Halt die libglfw3.a. Und eine .so gibt es auch nicht
Dann gib mal den Pfad zur ".a"-Datei an, vielleicht geht das.
Ansonsten kann man schauen, ob man irgendwie Shared Libraries erzeugen kann und es damit klappt. Oder man Versucht es über Pkg oder spielt noch etwas mit den FLAGS rum.
Ist echt ein Gefummel, eigentlich müsste das schon längst gehen.
Ich würde insgesamt auch eher dazu raten, nicht MinGW zu nutzen, außer es ist unbedingt nötig, aber ich weiß nicht, ob das mit dem Windows-Compiler besser ginge.
Du meinst so?
target_link_libraries(Tesst external/glfw/src/libglfw3.a)
Geht nicht... kommt das selbe
Hm, okay.
Wenn du
set(BUILD_SHARED_LIBS ON CACHE BOOL "")
machst, bekommst du dann eine ".so" Datei?
oder
target_link_libraries(Tesst ${GLFW3_LIBRARY} glfw)
(Anderer Name der Environment-Variable)
Also das war die ganze zeit auf on und jetzt mit dem targetlinklib kommt wieder:
undefined reference to `__imp_glfwInit'
Em... ich habe jezt grade meine Festplatte in einen Anderen PC gesteckt und da sah es zuerst so aus als hätte es funktioniert. Aber daan hat avira das geblockt. Dann musste ich den PC neustarten weil Avira sich nicht öffnen wollte und jetzt kommt
Process finished with exit code -1073741515 (0xC0000135)
Das auf einem Computer zu bauen und auf dem anderem auszuführen kann leicht schiefgehen. Besser du baust das auf dem anderem Rechner komplett neu (sprich überträgst die CMakeFiles und den Cahce nicht bzw. löschst diese, auch in allen Unterordnern).
EDIT:
Bzw. geht evtl.:
cmake --target clean
Wo gebe ich eigendlich diese commands ein? Und neu bauen würde sich jetzt nicht lohnen ich bin nur 2 Tage hier
Das gibst du in der MinGW-Konsole ein (wo die ist, kann ich dir nicht sagen).
Vielleicht hat deine IDE auch irgendwo extra einen Button dafür das aufzuräumen.
Und neu bauen musst du, sonst geht es nicht, ist auch kein Aufwand.
Aber er weis ja nicht was er aufräumen soll? Also er sagt halt cmake not found.
Ich bin wie gesagt neu
Cmake weiß, was es aufräumen soll. Aber natürlöich muss cmake erst einmal existieren, wnen du das nicht installiert hast, dann wird das nicht gehen.
Okay und jetzt sagt er mir Unknown argument --target
nein... auch nicht aber cmake --version geht also ist es installiert
Dann schau mal, ob in deinem Projekt ein "build"-Ordner ist und lösch den manuell. Wenn nicht, dann versuch einfach mal ganz normal das bauen des Projekts.
Habe den build ordner jetzt gelöscht aber es kommt beim starten immerncoh die gleiche Fehler meldung
Was heist denn bauen?! Ich dachte das heist starten
Jetzt sagt er mir wieder Permission denied obwohl ich avira wieder ausgemacht habe...
Dann starte das Programm, mit dem du das machen wolltest, als Administrator und versuch es noch einmal.
Dein Satz macht im Kontext keinen Sinn.
Du sollst tun, was du vorher tatest, nur eben als Administrator dieses Mal.
Er sagt zwar
cannot open output file Tesst.exe: Permission denied
Aber es gibt keine exe file mehr in dem project...
Nur noch a.exe aber das 4 mal
Er sagt, dass er die Datei nicht schreiben kann, da ihm die Zugriffsrechte fehlen. Deshalb als Administrator ausführen, dann hat er die Zugriffsrechte.
Wenn es auch als Administrator nicht geht, ist es doof, dann schauen, ob die die Zugriffsrechte an den verzeichnissen anpassen kannst und wenn das auch nicht geht, dann ist evtl. Hardware-Schreibschutz drauf oder so).
Ich verstehe die anleitungen auf google nicht wie ich eine cpp zu einer exe machen kann in mingw :/
Das macht cmake für dich.
Mach doch einfach dasselbe, was du an deinem anderem Computer auch gemacht hast.
Ah ja dann sagt er mir libgcc_s_seh-1.dll wurde nicht gefunden
also wenn ich es im cmd mache
Hä? In CLion habe ich einfach auf den grünen Pfeiul geclickt aber genau das funktioniert ja grade nichtmehr hä?
Aber gcc --version funktioniert ja? Dann ist es doch installiert oder nicht
Also folgendes sagt wir man einen Workaround macht:
Aber eigentlich sollte das gar nicht auftreten.
Mach mal ein "where gcc" oder "which gcc" in der Konsole und schau, wo das installiert ist und ob da irgendwo die dll rumliegt.
Ich rufe das ja grade so auf weil ich ja auf einem anderem pc bin
G:\msys64\mingw64\bin\gcc --version
Und bei dem link brauch ich doch ein programm code::Blocks ?
Soll das heißen, dein MinGW liegt auf der festplatte?
Du musst das auf deinem PC installieren, sonst wird das bauen kompliziert oder funktioniert garnicht.
Ich verstehe das nicht... gcc.exe exestiert. ich habe den bin pfad zu den system variablen hinzugefügt aber gcc --version funktioniert nicht :(
Oh ichmusste cmd nur neu öffnen
Starte die Konsole neu und versuch es noch einmal.
Du verwendest auch sicher die MinGW-Konsole und nicht etwa die CMD?
Em doch? Bei der mingw console hat garnichts gekalppt... aber jetzt geht es im cmd Also so halb XD
G:\Users\alpha\OneDrive\Desktop\Tesst\main.cpp:8:10: fatal error: GLFW/glfw3.h: No such file or directory
8 | #include <GLFW/glfw3.h>
| ^~~~~~~~~~~~~~
compilation terminated.
gcc.exe G:\Users\alpha\OneDrive\Desktop\Tesst\main.cpp
cannot open output file Tesst.exe: Permission denied 😅
Öffne die Konsole als Administrator und versuch es noch einmal.
(Für CMD: Suche -> "cmd" -> "Als Administrator ausführen")
Kommt das gleiche :( und ich bin mir sicher ich habe es richtig gemacht weil oben steht Adminestrator: Eingabeaufforderung
Ja, das dachte ich mir schon.
Ich frage mich ja, wie du überhaupt gcc verwenden kannst, wenn nicht über MinGW. Schu mal ob du irgendwo die MinGW-Konsole öffnen und es darüber versuchen kannst.
Ansonsten versuch mal
cmake -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON --build .
Und schu, ob dir das dann genauere Gründe liefert dafür, dass es den File nicht öffnen kann.
Du kannst auch mal schauen, ob du selbst einen File mit dem Namen über die Konsole erstellen kannst (notepad.exe <filename> und dann speichern).
CMake Error: Unknown argument --build
Und ja dann öffnet sich ein neues Fenster vom editor
und dann steht da speichern?
Oben "Datei -> Speichern". Soll halt testen, ob du die berechtigung hast oder ob dir das nur Unsinn erzählt.
CMake Error: Unknown argument --build
Dann
cmake --build -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON .
oder
cmake -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON .
Also er sagt nichts wenn ich auf speichern drücke.
Wenn ich die commands eingebe sagt er mir nur unknown argument .
Wird die Datei erstellt, wnen du auf "Speichgern" drückst?
Das mit dem "unknown argument" ist komisch. Dann schreib einfach mal in deine CMakeList folgendes:
set(CMAKE_VERBOSE_MAKEFILE ON)
set(VERBOSE ON)
und versuch es mit dem Command von vorhin.
Achso ich dachte es geht immnnoch um das txt... Ja wenn ich meinen pfad zu dem project eingebe macht er etwas. Keine Fehlermeldung
Aber keine exe im ordner
Was genau hast du jetzt wo gemacht und welche AUsgabe hast du erhalten?
.exe taucht evtl. im build-Ordner auf. Oder du musst noch ein
make
eingeben, damit es etwas tut.
Wenn ich das make hinter cmake mache kommt auch nichts und wenn ich es hinten drann mache sagt er ignored
Wenn du einfach nur make in dem Ordner ausführst passiert nichts? Keine Ausgabe?
Oder welche Ausgabe erhälst du?
C:\Windows\system32>cmake make -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON G:\Users\alpha\OneDrive\Desktop\Tesst
(Das ist der Befehl)
-- Using Win32 for window creation
-- Configuring done
-- Generating done
-- Build files have been written to: G:/Users/alpha/OneDrive/Desktop/Tesst
cmake make
Ne, mach
g:
cd G:\Users\alpha\OneDrive\Desktop\Tesst
Dann einfach nur
cmake -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON .
und danach
make
Funktioniert bis zum make dann sagt er gibt es nicht. Also in einem neuem Befehl. Wenn ich es nach dem da mit dem BOOL schreibe sagt er halt ignored
Dann installier dir erst make.
Ansonsten was meinst du mit "ignored"?
Geht denn
cmake -DCMAKE_VERBOSE_MAKEFILE=ON .
?
ja das geht hier:
G:\Users\alpha\OneDrive\Desktop\Tesst>cmake -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON . make
CMake Warning:
Ignoring extra path from command line:
"make"
-- Using Win32 for window creation
-- Configuring done
-- Generating done
-- Build files have been written to: G:/Users/alpha/OneDrive/Desktop/Tesst
Was meinst du mit make installieren? Cmake ist jetzt installiert
G:\Users\alpha\OneDrive\Desktop\Tesst>cmake -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON . make
Das ist immernoch invalid.
Was meinst du mit make installieren? Cmake ist jetzt installiert
Make ungleich CMake. Musste ich auch erst lernen.
Also suche ich jetzt nach was? Make installieren ? da kommen bestimmt nicht die sachen die ich brauche
Ja, doch. Make. Wenn wir das so bauen braucht es Make.
Das ganze für MinGW. Dürfte sich vermutlich so einfach installieren lassen wie vorhin CMake und GCC. (Wobei alles eigentlich Standradmäßig bei MinGW dabeisein sollte iirc, keine Ahnung, was du da machst).
So ich habe das jewtzt von dieser website installiert aber es kommt immernoch das selbe.
Hast du es dieses Mal korrekt ausgeführt?
Ist Make im PATH?
Hast du die Konsole neu gestartet nachdem du den PATH upgedatet hast?
Jetzt sagt er immernoch
cmake -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON . make
ignore
obwohl ich cmd neu gestartet habe
Ah tut mir leid trotzdem:
make: *** Keine Targets angegeben und keine »make«-Steuerdatei gefunden. Schluss.
Hm, okay, blöd, dann lässt sich das so nicht bauen.
Dann versuch es wieder mit nur
cmake --build .
aber mit der geänderten CMakeList mit den Verbose drinnen.
Ja wie soll es denn dann funktionieren? Ich dachte du baust das Projekt das du gestern auch bauen wolltes?
Ja aber gestern habe ich es ja noch über CLion gemacht und jetzt geht das ja nichtmehr wegen permission denied
Wenn du in CLion das "Permisson Denied" hattest, dann hätten wir da wieterschauen sollen.
Und CMakeList brauchst du trotzdem.
Hast du CLion schon einmal als Administrator ausgeführt?
Ja guut XD jetzt ist aber noch ein problem... Irgendwie sind jetzt die run configurations gelöscht und wenn ich einen neue erstelle sagt er "nothing to run on" immer wieder neue probleme...
Dann erstell halt die RunConfigurations neu. Im Zweifelsfalle erstellst du dir ein neues Projekt und kopierst dir die Configurations rüber.
Vielleicht ist das aber auch schlicht etwas, was auf deinem anderen Rechner gespeichert ist und sich nicht über die Festplatte übertragen lies?
Hm das kann sein... Naja dann schreibe ich Sontag abend nochmal wenn ich wieder zuhause bin okay?
So ich bin wieder zuhause ich hoffe du bist noch online :)
Also wenn ich auf start drücke kommten halt so nachrichten die erstmal gut aussehen:
[1/18] Building CXX object CMakeFiles/Tesst.dir/main.cpp.obj
[2/18] Building C object external/glfw/src/CMakeFiles/glfw.dir/win32_thread.c.obj
[3/18] Building C object external/glfw/src/CMakeFiles/glfw.dir/vulkan.c.obj
[4/18] Building C object external/glfw/src/CMakeFiles/glfw.dir/win32_joystick.c.obj
[5/18] Building C object external/glfw/src/CMakeFiles/glfw.dir/win32_init.c.obj
[6/18] Building C object external/glfw/src/CMakeFiles/glfw.dir/monitor.c.obj
[7/18] Building C object external/glfw/src/CMakeFiles/glfw.dir/init.c.obj
[8/18] Building C object external/glfw/src/CMakeFiles/glfw.dir/context.c.obj
[9/18] Building C object external/glfw/src/CMakeFiles/glfw.dir/window.c.obj
[10/18] Building C object external/glfw/src/CMakeFiles/glfw.dir/input.c.obj
[11/18] Building C object external/glfw/src/CMakeFiles/glfw.dir/win32_time.c.obj
[12/18] Building C object external/glfw/src/CMakeFiles/glfw.dir/osmesa_context.c.obj
[13/18] Building C object external/glfw/src/CMakeFiles/glfw.dir/win32_monitor.c.obj
[14/18] Building C object external/glfw/src/CMakeFiles/glfw.dir/wgl_context.c.obj
[15/18] Building C object external/glfw/src/CMakeFiles/glfw.dir/egl_context.c.obj
[16/18] Building C object external/glfw/src/CMakeFiles/glfw.dir/win32_window.c.obj
[17/18] Linking C static library external\glfw\src\libglfw3.lib
[18/18] Linking CXX executable Tesst.exe
Aber dann kommt halt trotzdem
FAILED: Tesst.exe
cmd.exe /C
C:\Users\alpha\OneDrive\Desktop\Tesst/main.cpp:77: undefined reference to `__imp_glfwInit'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\alpha\OneDrive\Desktop\Tesst/main.cpp:79: undefined reference to `__imp_glfwTerminate'
collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
Dann machen wir da weiter, wo wir aufgehört haben. Mit
set(GLFW_LIBRARY_TYPE SHARED)
Vielleicht funktioniert es, wenn man GLFW dynamisch linkt.
Beim reloaden kommt das
CMake File API: C:\Users\alpha\OneDrive\Desktop\Tesst: failed to load from 'C:\Users\alpha\OneDrive\Desktop\Tesst\.cmake\api\v1\reply\target-glfw-Debug-a04d8ad351b166d44a1b.json'
Aber das kam auch ohne die neue line...
Warte... vielleicht können wir uns auch mal diese file anschauen
da steht "external/glfw/src/libglfw3.lib"
a
Dann lösch den .cmake-Ordner und den CMake-Cahe in dem Ordner.
Ah doch nicht die datei gibt es
Printed CMake noch das Commando aus? Weil die letzten Male hat das ja eine .a-Datei verlinkt und nicht .lib
Aber vieleicht haben wir das auch geändert als wir das Suffix hgeändert haben.
Hm... das ist jetzt blöd... Ich kann den ordner nicht löschen weil das Verzeichnis beschädigt ist?
Beschädigt ist schlecht. Sagt das wirklich beschädigt?
Mach mal alles andere zu, was evtl. den Ordner verwendet und lösch die dann über den Explorer.
Ich versuch es ja über den explorer... habe CLion schon geschlossen und nurnoch spotify und ein spiel offen
Dann ist es schlecht.
Kopier dir als ersten Schritt alle wichtigen Daten auf einen anderen Datenträger, dann chkdsk auf den Datenträger oder gleich neu formattieren oder einen neuen holen.
Ja... ist eine 5mb/s HDD und da sind 433 GB drauf... Das dauert bestimmt 2 Tage XD
Also prinzipiell kannst du auch versuchen die zu reparieren ohne die vorher zu klonen, aber kann halt leicht Zeug drauf kaputt gehen.
Stell am besten eine neue Frage dazu.
Wenn du meinst. Aber wie gesagt, eigene Gefahr. Im Zweifelsfalle erst wichtige Daten sichern.
Hab es jetzt einfach in einen anderen ordner verschoben problem gelöt oder? 😅
Naja ne. Wenn die Datei beschädigtw ar, dann kann es gut sein, dass die Platte beschädigt ist. Ich würde auf jeden Fall zeitnah zumindest die wichtigsten Dateien backupen.
Ja mal später sehen...
Also jetzt reloadet er und beim starten kommt wieder undefined reference
Ja mal später sehen...
Das sollte möglichst früh geschehen, denn wenn die Platte hin ist macht jedes arbeiten darauf die Chance höher, dass Daten vcerloren gehen.
Also jetzt reloadet er und beim starten kommt wieder undefined reference
Wie sieht der Command jetzt aus? Er müsste jetzt eine Shared-Lib verwenden statt einer statischen.
Welchen command meinst du?
====================[ Build | Tesst | Debug ]===================================
"C:\Program Files\JetBrains\CLion 2022.2.4\bin\cmake\win\bin\cmake.exe" --build C:\Users\alpha\OneDrive\Desktop\Tesst --target Tesst -j 9
[1/17] Building C object external/glfw/src/CMakeFiles/glfw.dir/init.c.obj
[2/17] Building C object external/glfw/src/CMakeFiles/glfw.dir/window.c.obj
[3/17] Building C object external/glfw/src/CMakeFiles/glfw.dir/win32_joystick.c.obj
[4/17] Building C object external/glfw/src/CMakeFiles/glfw.dir/egl_context.c.obj
[5/17] Building C object external/glfw/src/CMakeFiles/glfw.dir/vulkan.c.obj
[6/17] Building C object external/glfw/src/CMakeFiles/glfw.dir/context.c.obj
[7/17] Building C object external/glfw/src/CMakeFiles/glfw.dir/win32_init.c.obj
[8/17] Building C object external/glfw/src/CMakeFiles/glfw.dir/input.c.obj
[9/17] Building C object external/glfw/src/CMakeFiles/glfw.dir/monitor.c.obj
[10/17] Building C object external/glfw/src/CMakeFiles/glfw.dir/win32_time.c.obj
[11/17] Building C object external/glfw/src/CMakeFiles/glfw.dir/win32_thread.c.obj
[12/17] Building C object external/glfw/src/CMakeFiles/glfw.dir/osmesa_context.c.obj
[13/17] Building C object external/glfw/src/CMakeFiles/glfw.dir/win32_monitor.c.obj
[14/17] Building C object external/glfw/src/CMakeFiles/glfw.dir/wgl_context.c.obj
[15/17] Building C object external/glfw/src/CMakeFiles/glfw.dir/win32_window.c.obj
[16/17] Linking C static library external\glfw\src\libglfw3.lib
[17/17] Linking CXX executable Tesst.exe
FAILED: Tesst.exe
cmd.exe /C "cd . && C:\msys64\mingw64\bin\c++.exe -g CMakeFiles/Tesst.dir/main.cpp.obj -o Tesst.exe -Wl,--out-implib,libTesst.dll.a -Wl,--major-image-version,0,--minor-image-version,0 external/glfw/src/libglfw3.lib -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ."
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/Tesst.dir/main.cpp.obj: in function `main':
C:\Users\alpha\OneDrive\Desktop\Tesst/main.cpp:77: undefined reference to `__imp_glfwInit'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\alpha\OneDrive\Desktop\Tesst/main.cpp:79: undefined reference to `__imp_glfwTerminate'
collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
Hier vielleicht ist ja etwas in der falschen Reihenfolge
cmake_minimum_required(VERSION 3.23)
project(Tesst)
set(SOURCE_FILES main.cpp) # welche Dateien kompiliert werden sollen
set(GLFW_SOURCE_DIR "external/glfw")
set(GLFW_LIBRARY_TYPE SHARED)
set(BUILD_SHARED_LIBS ON CACHE BOOL "")
set(GLFW_BUILD_EXAMPLES OFF CACHE BOOL "")
set(GLFW_BUILD_TESTS OFF CACHE BOOL "")
set(GLFW_BUILD_DOCS OFF CACHE BOOL "")
set(GLFW_INSTALL OFF CACHE BOOL "")
set(GLFW_DLL ON CACHE BOOL "")
set(CMAKE_STATIC_LIBRARY_SUFFIX ".lib")
set(CMAKE_SHARED_LIBRARY_SUFFIX ".dll")
include_directories(external/glfw/include external/glfw/deps)
add_subdirectory(external/glfw)
include_directories(external/glfw/include external/glfw/deps)
add_executable(Tesst main.cpp)
target_link_libraries(Tesst ${GLFW3_LIBRARY} glfw)
Okay, sehr komisch. Wir dagen GLFW, dass es als Shared-Lib baueh soll, aber es baut trotzdem statisch.
Kannst du mal in den CMakkeList im GLOFW-Ordner eine Ausgabe einbauen, die dir prüft auf welchen Wert "GLFW_LIBRARY_TYPE" gestezt ist? Nicht dass das aus irgendwelchen Gründen da nicht ankommt.
Er gibt SHARED aus.
Aber
if (BUILD_SHARED_LIBS)
set(_GLFW_BUILD_DLL 1)
message("aaaaaaaaaaa")
endif()
Das gibt er nicht aus ist das richtig so?
Dann mach mal das
CACHE BOOL ""
weg, vielleicht geht es dann. Ich habe auch keine Ahnung, was der Teil genau tut.
Bzw. lösch die Zeilen
set(BUILD_SHARED_LIBS ON CACHE BOOL "")
und
set(GLFW_DLL ON CACHE BOOL "")
Außerdem lösch auch mal die .cmake-Directories und Caches sowohl im Projektordner als auch in den Unterordnern (insbesondere in den GLFW-Ordnern), vielleicht tut es dnan, was es soll.
ich meine, ich verstehe nicht, wieso das Ding nicht dynamisch baut, obwohl es eben genau das tun sollte.
Hm sollte ich vielleicht einfach mal ein neues project machen? Weil ich versuch ja immer den ordner zu löschen also den CMakeFiles und den .cmake und einen ache fid ich hier nicht
Wenn es dir keine Umstände macht könnte man das mal versuchen, ja. Dann aber auch das GLFW neu herunterladen bzw. darauf achten, dass du keine der Filkes, die durch CMake erstellt wurden, kopierst.
Bzw. vielleicht reicht es auch schon, den GLFW-Ordner zu löschen und neu zu füllen.
Naja ich das project hat ja schon was durch gemacht vielleicht ist da einfach was schief gelaufe ich mach mir jetzt ein neues ich soll den source code runterladen oder? Also GLFW
ich soll den source code runterladen oder? Also GLFW
Ja, damit du halt nicht die CMakeFiles rüberkopierst.
So frisch erstellt und GLFW runtergeladen. die h datei ist unter external/glfw-3.3.8/include/GLFW/glfw3.h
Was muss ich jetzt genau in alle sachen schreiben?
Dann musst du die Pfade in der CMakeList anpassen:
cmake_minimum_required(VERSION 3.23)
project(Tesst)
set(SOURCE_FILES main.cpp) # welche Dateien kompiliert werden sollen
set(GLFW_SOURCE_DIR "external/glfw-3.3.8")
set(GLFW_LIBRARY_TYPE SHARED)
set(GLFW_BUILD_EXAMPLES OFF)
set(GLFW_BUILD_TESTS OFF)
set(GLFW_BUILD_DOCS OFF)
set(GLFW_INSTALL OFF)
set(CMAKE_STATIC_LIBRARY_SUFFIX ".lib")
set(CMAKE_SHARED_LIBRARY_SUFFIX ".dll")
include_directories(external/glfw/include external/glfw-3.3.8/deps)
add_subdirectory(external/glfw-3.3.8)
include_directories(external/glfw-3.3.8/include external/glfw-3.3.8/deps)
add_executable(Tesst main.cpp)
target_link_libraries(Tesst ${GLFW3_LIBRARY} glfw)
vielleicht muss man
set(GLFW_SOURCE_DIR "external/glfw-3.3.8")
auch zu
set(GLFW_SOURCE_DIR "external/glfw-3.3.8/src")
ändern, das würde irgendwie Sinn machen. Aber vielleicht bbraucht amn das auch garnicht.
EM... keine Fehlermeldung :D er sagt helloworld (ich habe dannach glfwInit() geschrieben)
oh... wenn ich den example text nehme von glfw sagt er undefined reference __imp_glClear
Heißt, jetzt geht es? (Wenn ja dann: Endlich! Hurra!)
Dann schau auch mal, ob es mit
set(GLFW_LIBRARY_TYPE STATIC)
geht, das willst du vielleicht später haben, wenn du das auf einem System bauen aber auf dem anderem ausführen möchtest.
Außerdem wüsste man dann, ob wir jetzt die ganze Zeit unnötiges Zeug gemacht haben oder ob es tatsächlich nötig war, das dynamisch zu bauen.
Er sagt immernoch undefined reference o '__imp_glClear'
Das ist aber jetzt eine andere Fehlermeldung, also ein Fortschritt.
Du brauchst nicht nur GLFW, sondern auch OpenGL.
find_package(OpenGL REQUIRED)
include_directories(${OPENGL_INCLUDE_DIRS})
und vielleicht reicht das auch schon.
Muss ich noch was runterladen dafür? also das orignial OpenGL ?
Und was muss ich untertarget Link libraries angeben
OpenGL sollte das Betriebssystem von sich aus bereitstellen.
und für link_libraries gib erst einmal nichts an und schau ob es geht. Wnen nicht schaue ich mal nach, was man da angeben müsste.
Okay, das wäre dann wohl:
target_link_libraries(Tesst ${GLFW3_LIBRARY} glfw ${OPENGL_LIBRARIES})
Ja geht :D
Aber direct das erste im video geht nicht...
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_PROFILE);
GLFWwindow* window = glfwCreateWindow(800, 800, "First", nullptr, nullptr);
if (window == nullptr) {
std::cout << "afaf";
glfwTerminate();
return -1;
}
Er return -1 liegt dasirgendwas an der lib vielleicht?
Folgendes kann dir vielleicht helfen:
https://www.glfw.org/docs/3.0/group__error.html
An sich sieht der Code korrekt aus, aber kann ich nicht sicher sagen.
Sorry das ich nochmal störe... ich muss noch glad installieren aber das ist eine ganz andere struktur als es GLFW war! Es gibt nichts mit Cmake
Er will nicht...
add_subdirectory(${GLAD_SOURCES_DIR}/cmake glad_cmake)
CMake Error at CMakeLists.txt:33 (add_subdirectory):
add_subdirectory given source "C:/Users/alpha/3D
Objects/backR/external/glad//cmake" which is not an existing directory.
Auch wenn ich bei set(GLAD_SOURCES_DIR das / am ende weglasse
Objects/backR/external/glad/cmake" which is not an existing directory.
Hast du dir glad denn auch heruntergeladen und an die entsprechende stelle gepackt?
Bzw. musst du dir das in deinen extrenal-Ordner packen und die Pfade entsprechend anpassen.
ja der include ist bei external/glad/include
Aber heist add_subdirectory nicht das er ein neues erstellt? Wie kann es dann ein fehler sein wenn es noch nicht exestiert
Dein CMake müsste etwa folgendes sein:
set(GLAD_SOURCES_DIR "${PROJECT_SOURCE_DIR}/external/glad/")
add_subdirectory("${GLAD_SOURCES_DIR}/cmake" glad_cmake)
glad_add_library(glad_gl_core_33 REPRODUCIBLE API gl:core=3.3)
target_link_libraries(Tesst glad_gl_core_33 ${GLFW3_LIBRARY} glfw ${OPENGL_LIBRARIES})
Evtl. ist aber auch das "PROJECT_SOURCE_DIR" woanders, evtl. dann versuchen mit
set(GLAD_SOURCES_DIR "/external/glad/")
Aber heist add_subdirectory nicht das er ein neues erstellt? Wie kann es dann ein fehler sein wenn es noch nicht exestiert
Nein, der fügt das existierende Subdirectory zum Projekt hinzu.
Egal... Also es gibt keinen cmake ordner in glad/src da ist nur eine .c drinn
Lad dir GLAD von hier herunter:
https://github.com/Dav1dde/glad
Da gibt es das cmake-Directory.
Ist das ganze das glad? Da sehe ich aber keinen include ordner?
CMake Error at C:/Program Files/JetBrains/CLion 2022.2.4/bin/cmake/win/share/cmake-3.23/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find PythonInterp (missing: PYTHON_EXECUTABLE)
Nein? Wie gesagt ich bin ganz neu XD habe nur mingw installiert für die grundlagen
also einfach python runterladen? in den default ordner?
So er zeigt mir keine Fehler an aber
#include <glad/glad.h>
exestiert nicht. zwar glad/gl.h aber da gibt es die funktiion gladLoadGL() nicht
Im Beispiel includen sie auch "glad/gl.h":
https://github.com/Dav1dde/glad/blob/glad2/example/c%2B%2B/multiwin_mx/multiwin_mx.cpp
Aber schau mal, ob die es denn damit geht, vielleicht ist die funktioni in einem anderem Hearer definiert und wird indirekt inkludiert.
Hm... https://youtu.be/45MIykWJ-C4?t=667 hier schreibt er es grade rein... Ist das wichtig für später? Gab es da ne Ändrung? das Video ist schon 1 Jahr alt
Kann ich dir nicht sagen. Probier es aus und wnen es nicht geht, dann recherchiere, was du stattdessen verwenden musst oder ob es evtl. sogar ohne geht.
Okay einfach mal schauen :) Danke hätte ich wieder nicht ohne dich geschafft... Warum brauche ich denn immer ein extra Version wo es cmake gibt und die anderen nicht?
Vielleicht haben die anderen nur nicht gezeigt, wie sie das gebaut haben, oder haben eine Umgebung verwendet, wo das schon installiert war oder so? Kann ich dir nicht beantworten die Frage.
Jetzt geht es ohne Grund nichtmehr...
FAILED: gladsources/glad_gl_core_33/include/KHR/khrplatform.h gladsources/glad_gl_core_33/include/glad/gl.h gladsources/glad_gl_core_33/src/gl.c gladsources/glad_gl_core_33/args.txt C:/Users/alpha/3D Objects/backR/cmake-build-debug/gladsources/glad_gl_core_33/include/KHR/khrplatform.h C:/Users/alpha/3D Objects/backR/cmake-build-debug/gladsources/glad_gl_core_33/include/glad/gl.h C:/Users/alpha/3D Objects/backR/cmake-build-debug/gladsources/glad_gl_core_33/src/gl.c C:/Users/alpha/3D Objects/backR/cmake-build-debug/gladsources/glad_gl_core_33/args.txt
Das System kann den angegebenen Pfad nicht finden.
cmd.exe /C "cd /D "C:\Users\alpha\3D Objects\backR\cmake-build-debug\external\glad" && echo Cleaning "C:/Users/alpha/3D Objects/backR/cmake-build-debug/gladsources/glad_gl_core_33" && "C:\Program Files\JetBrains\CLion 2022.2.4\bin\cmake\win\bin\cmake.exe" -E remove_directory "C:/Users/alpha/3D Objects/backR/cmake-build-debug/gladsources/glad_gl_core_33" && "C:\Program Files\JetBrains\CLion 2022.2.4\bin\cmake\win\bin\cmake.exe" -E make_directory "C:/Users/alpha/3D Objects/backR/cmake-build-debug/gladsources/glad_gl_core_33" && echo Generating with args --out-path "C:/Users/alpha/3D Objects/backR/cmake-build-debug/gladsources/glad_gl_core_33" --api gl:core=3.3 --reproducible c && C:\Users\alpha\AppData\Local\Programs\Python\Python311\python.exe -m glad --out-path "C:/Users/alpha/3D Objects/backR/cmake-build-debug/gladsources/glad_gl_core_33" --api gl:core=3.3 --reproducible c && echo Writing "C:/Users/alpha/3D Objects/backR/cmake-build-debug/gladsources/glad_gl_core_33/args.txt" && echo --out-path "C:/Users/alpha/3D Objects/backR/cmake-build-debug/gladsources/glad_gl_core_33" --api gl:core=3.3 --reproducible c > "C:/Users/alpha/3D Objects/backR/cmake-build-debug/gladsources/glad_gl_core_33/args.txt""
ninja: build stopped: subcommand failed.
Den ersten pfad also
"C:\Users\alpha\3D Objects\backR\cmake-build-debug\external\glad"
gbit es nicht
(Passiert auch wenn ich den Ganzen code auskommentiere)
C:/Users/alpha/3D Objects/backR/cmake-build-debug/gladsources/glad_gl_core_33
Das ist halt wieder ein anderer Pfad, als der, in dem dein glad liegt, oder? Prüf das mal und schau, ob du da etwas umändern musst.
Vielleicht musst du auch erst irgendwie GLAD generieren und dann geht das, keine Ahnung.
Man kann sich auch mal folgendes anschauen:
https://github.com/Dav1dde/glad/blob/glad2/cmake/CMakeLists.txt
oben steht, wir man z.B. den Pfad, an dem das generiert wird, ändern kann, evtl. kannst du damit dem Pfad passend setzen.
Vielleicht musst du auch nur die reihenfolge der Befehle verändern, vielleicht will der die Libraries laden bevor sie erzeugt wurden oder soetas.
Hm das kann vielleicht sein ich habe es neu sortiert aber ich bin mir nicht sicher ob es vor dem Fahler oder nach dem Fehler war
Hier ist mal meine cmake list:
cmake_minimum_required(VERSION 3.23)
project(backR)
add_executable(backR main.cpp)
set(SOURCE_FILES main.cpp) # welche Dateien kompiliert werden sollen
set(GLFW_SOURCE_DIR "external/glfw-3.3.8/src")
set(GLAD_SOURCES_DIR "external/glad")
set(GLFW_LIBRARY_TYPE STATIC)
set(GLFW_BUILD_EXAMPLES OFF)
set(GLFW_BUILD_TESTS OFF)
set(GLFW_BUILD_DOCS OFF)
set(GLFW_INSTALL OFF)
set(CMAKE_STATIC_LIBRARY_SUFFIX ".lib")
set(CMAKE_SHARED_LIBRARY_SUFFIX ".dll")
find_package(OpenGL REQUIRED)
include_directories(${OPENGL_INCLUDE_DIRS})
add_subdirectory(external/glfw-3.3.8)
include_directories(external/glfw-3.3.8/include external/glfw-3.3.8/deps)
add_subdirectory("${GLAD_SOURCES_DIR}/cmake" glad_cmake)
glad_add_library(glad_gl_core_33 REPRODUCIBLE API gl:core=3.3)
target_link_libraries(backR glad_gl_core_33 ${GLFW3_LIBRARY} glfw ${OPENGL_LIBRARIES})
Müsste man schauen, wie deine Verzeichnisstruktur jetzt aussieht und was genau du beim Umstrukturieren gemacht hast.
Das "Kann den angegebenen Pfad nicht finden" kann sich leider auf so ziemlich jeden Pfad und jedes Programm beziehen, welches in der Fehlermeldung vorkommt.
Wenn es vorher funktioniert hat, evtl. noch einmal neu aufsetzen?
Hab ich mior auch schon gedacht aber wele ordner muss ich dafür löschen
Das Build-Directory "cmake-build-debug" und die CMakeCache-Datei. Evtl. noch diverse .cmake oder CMakeFiles-Verzeichnisse.
Gelöscht neu gebaut immernoch selber Fehler :(
Versuch mal
glad_add_library(glad_gl_core_33 REPRODUCIBLE LOCATION "/glad-build" API gl:core=3.3)
Oder alternativ mit anderem Pfad für Location.
Und den Ordner erstellst du dann im Zweifelsfalle falls er nicht existiert.
Ich vermute da könnte ein Bug in GLAD sein.
In deinem Projektordner. Da wo halt der Pfad hinzeigt, den du da angibst.
Hm... ist das richtig so? sollte es nicht in external sein?
Was soll richtig sein? Der "build-debug"-Ordner ist kein ordner, in dem du irgendetwa smachen solltest, das sollte der Ordner sein, den CMake erstellt.
Ja aber kann ja sein das ein Phad komisch ist der das falsch aufbaut?
Muss die library nicht wie glfw ion external sein? weil es ist ja auch der ordner wo die src drin ist
Ne, offenbar nicht. das baut die Library in gladsources.
Aber ich sehe auch gerade, der Lösungsvorschlag, den ich angegeben habe, funktioniert eher nicht.
Das Problem scheint wohl zu sein, dass die CakeList von GLAD die Variable "GLAD_SOURCES_DIR" überschreibt.
Vielleicht kannst du es lösen, indem du die nicht setzt oder indem du die Zeile in derden CMAkeList, die das tut, auskommentierst.
Wenn ich e snicht setzte kommt halt
CMake Error at CMakeLists.txt:28 (add_subdirectory):
add_subdirectory given source "./..//cmake" which is not an existing
directory. Gibt es dann anscheinend nicht
Na du musst dann natürlich unten das directory ausschreiben:
add_subdirectory("external/glad/cmake" glad_cmake)
Okay okay neuer Fehler :D
C:\Users\alpha\AppData\Local\Programs\Python\Python311\python.exe: No module named glad
Beim ausführen von der cpp datei
Mach mal noch einmal rückgängig, was du gerade eben gemacht hast und nutze folgende Zeile
add_subdirectory("external/glad/cmake")
und schau, ob das geht. Offenbar ist der fehler im Endeffekt, dass das Ding "glad_cmake" erstellt und da die CMakeFile reinkopiert, dadurch aber der relative Pfad zu glad nicht mehr stimmt.
nein
cmake_minimum_required(VERSION 3.23)
project(backR)
set(SOURCE_FILES main.cpp) # welche Dateien kompiliert werden sollen
add_executable(backR main.cpp)
set(GLFW_SOURCE_DIR "external/glfw-3.3.8/src")
#set(GLAD_SOURCES_DIR "external/glad")
set(GLFW_LIBRARY_TYPE STATIC)
set(GLFW_BUILD_EXAMPLES OFF)
set(GLFW_BUILD_TESTS OFF)
set(GLFW_BUILD_DOCS OFF)
set(GLFW_INSTALL OFF)
set(CMAKE_STATIC_LIBRARY_SUFFIX ".lib")
set(CMAKE_SHARED_LIBRARY_SUFFIX ".dll")
find_package(OpenGL REQUIRED)
include_directories(${OPENGL_INCLUDE_DIRS})
add_subdirectory(external/glfw-3.3.8)
include_directories(external/glfw-3.3.8/include external/glfw-3.3.8/deps)
add_subdirectory("external/glad/cmake")
glad_add_library(glad_gl_core_33 REPRODUCIBLE LOCATION "/glad-build" API gl:core=3.3)
target_link_libraries(backR glad_gl_core_33 ${GLFW3_LIBRARY} glfw ${OPENGL_LIBRARIES})
Mach mal
set(GLAD_SOURCES_DIR "external/glad")
und
add_subdirectory("$(GLAD_SOURCES_DIR}/cmake")
Hm... nein Hier die ganze fehlermeldung
C:\Users\alpha\AppData\Local\Programs\Python\Python311\python.exe: No module named glad
FAILED: /glad-build/include/KHR/khrplatform.h /glad-build/include/glad/gl.h /glad-build/src/gl.c /glad-build/args.txt
cmd.exe /C "cd /D "C:\Users\alpha\3D Objects\backR\cmake-build-debug\external\glad" && echo Cleaning /glad-build && "C:\Program Files\JetBrains\CLion 2022.2.4\bin\cmake\win\bin\cmake.exe" -E remove_directory /glad-build && "C:\Program Files\JetBrains\CLion 2022.2.4\bin\cmake\win\bin\cmake.exe" -E make_directory /glad-build && echo Generating with args --out-path /glad-build --api gl:core=3.3 --reproducible c && C:\Users\alpha\AppData\Local\Programs\Python\Python311\python.exe -m glad --out-path /glad-build --api gl:core=3.3 --reproducible c && echo Writing /glad-build/args.txt && echo --out-path /glad-build --api gl:core=3.3 --reproducible c > /glad-build/args.txt"
Dieser Ordner huier exestiert:
"C:\Users\alpha\3D Objects\backR\cmake-build-debug\external\glad"
also backR/cmake-build-debug/external/glad gibt es
Mach mal die Location noch einmal weg und schau ob das etwas bringt.
Ein Problem scheint gelöst, aber jetzt gibt es ein anderes. Das Python findet den Pfad zum Module nicht.
#set(GLAD_SOURCES_DIR "external/glad")
auskommentiert und
add_subdirectory("external/glad/cmake")
kommt das selbe bei raus
Also das ändert doch eig nichts oder?
Nicht auskommmentieren. Ich meine
glad_add_library(glad_gl_core_33 REPRODUCIBLE API gl:core=3.3)
Versuch erst das und wenn es nicht geht dann
set(PYTHONPATH "${GLAD_SOURCES_DIR}")
Nope... da war aber gesnter irgendwie so ein __init__.py in externl das ist weg aber auch schon länger wra das vielleicht wichtifg?
Ja, das kann eben hierfür der Grund sein. Wo war das drinnen? Und wieso ist das jetzt weg?
Habs gelöscht weil es sich ja auch automatisch erstellt hat dachte ich es erstellt sich wieedr neu 😅
Naja, davon wäre auch auszugehen gewesen. Aber offenbar erstellt es die nicht neur.
Also würde ich sagen, wieder neu aufsetzen das Projekt. Oder aber du schaust, ob du die automatisch erstellen Dateien (auch in Unterordnern) so gelöscht bekommst, dass es die Datei die es braucht wieder erstellt.
Alsoo neu alles runterladen und neues Project erstellen?
Ja so inetwa. Wobei ich erst rumprobieren würde ob ich irgendwie die richtige Datei löschen kann, damit es das Python automatisch neu baut.
Ah ich konte es wiederherstellen aber die datei ist leer also die __init__.py
Wie konntest du das wiederherstellen? Hat das das System selbst gebaut? Wenn nicht, dann bringt dir das evtl. eher weniger nehme ich an.
Ich weiß leider auch nicht, woher diese Datei kommen könnte.
Hm, ja. Dann ist's fraglich, ob es etwas bringt.
Manchmal ist das aber auch echt ein Gefrickle mit den Kack Libraries. ich meine, warum kann das denn nicht einfach auf Anhieb funktionieren? Mir scheint, die Entwickler denken nicht mit, obwohl die genau dasselbe Problem haben und sich genauso darüber aufregen.
https://github.com/Dav1dde/glad/issues/392
;-) Wir haben einen Bug gefunden (zumindest anscheinend).
Nichts. Denn unser Problem liegt leider an einer anderen Stelle 8was vielleicht auch ein Bug ist, aber das müsste man sehen).
Hm okay... vielleicht hilft dch neues project nochmal bauen?
muss ich glfw und glad neu runterladen? Oder kann ich den external ordner einfach rüberziehen
Wenn da con CMake Dateien drinnen gebaut wurden kann das Zeug kaputt machen. ich würde das neu runterladen um sicherzugehen
(bzw. ich würde eher die Ordner löschen, das klappt normalerweise bei mir).
Das bringt dir ja recht wenig, dann müsstest du die Libs ja dennoch neu runterladen.
Die die CMake automatisch erstellt. Aber das verhält sich teilweise auch anders auf anderen Systemen.
CMakeFiles-Ordner und CMakeCache.txt ist das bei mir, im Parent-Ordner und in den Unterordnern.
Hm... kommt das gleiche habe jetzt alles neu gemacht
Kannst du mir vielleicht die Liste complett nochmal erstellen das da keine mini fehler drinn sind die man übersieht?
Okay, das ist blöd.
Dann noch einmal zu
set(ENV{PYTHONPATH} "${GLAD_SOURCES_DIR}")
mach mal:
set(ENV{PYTHONPATH} ENV{PYTHONPATH}":${GLAD_SOURCES_DIR}/glad")
Dann nur
set(ENV{PYTHONPATH} ENV{PYTHONPATH}":${GLAD_SOURCES_DIR}")
das sollte eigentlich gehen.
Ansonsten setz dir mal deinen PYTHONPATH über die Konxole manuell und schau, ob es dann geht.
zu glad in external oder zu glad in cmake-build-debug/external ?
Ne, du sollst in der Konsole das ausfüheren und den kompletten abvsoluten Pfad nehmen:
set PYTHONPATH="<pfad zu glad>"
und dann schauen, ob es geht.
Aber ich baue ja über CLion und da kann ich nichts in die console schreiben?
Hm, okay, dnan geht das nicht. blöd.
Dann versuch mal folgendes:
https://github.com/microsoft/vcpkg/pull/7051
Dein Python-Folder dürfte folgender sein:
C:\Users\alpha\AppData\Local\Programs\Python\Python311
Anstatt die zu löschen benennst du die nur um (häng ein ".old" hinten dran).
Dann heißt die vermutlich python311?
Aber mal eine andere Sache:
Kannst du mal in der CMakeList in glad ausgeben, welchen Wert die Variable "CMAKE_CURRENT_LIST_DIR" hat?
Mir scheint nämlich aus irgendwelchen Gründen kopiert CMake die CMakeList in das build-Dir, aber die anderen Dateienn nicht und dann gehte s schief.
Kannst du mir auch einmal einen vollständigen Baum des Build-Directories geben?
C:/Users/alpha/3D Objects/backroomsC/external/glad/cmake
ich glaube das ist die ausgabe (hab es ganz am ende der list geschrieben)
Darunter kam dann noch
-- Glad Library 'glad_gl_core_33'
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/alpha/3D Objects/backroomsC/cmake-build-debug
Bitte mach eine Ausgabe in der CMakeList. Denn das wechselt in ein anderes Directory als es sollte (das wechselt in BINARY_DIR/external/glad statt in SOURCE_DIR/external/glad).
Wie? ich habe in external/glad/cmake/cmakeLists.txt am ende das reingeschrieben
Ah okay, habe mich da etwas verlesen.
Dann bräuchte ich noch einmal den Fehler den dir cmake ausgibt.
Welchen Fehler? Wenn ich das programm starte kommt der nicht gefunden Fehler von python
Die Fehlermeldung wie vorhin halt auch. Mit dem Command, das fehlgeschlagen ist.
Ja der kommt beim Starten vom programm und nicht beim CMAKE ausführen?
Aber hier ist er falls du den meintest
C:\Users\alpha\AppData\Local\Programs\Python\Python311\python.exe: No module named glad
FAILED: /glad-build/include/KHR/khrplatform.h /glad-build/include/glad/gl.h /glad-build/src/gl.c /glad-build/args.txt
cmd.exe /C "cd /D "C:\Users\alpha\3D Objects\backroomsC\cmake-build-debug\external\glad" && echo Cleaning /glad-build && "C:\Program Files\JetBrains\CLion 2022.2.4\bin\cmake\win\bin\cmake.exe" -E remove_directory /glad-build && "C:\Program Files\JetBrains\CLion 2022.2.4\bin\cmake\win\bin\cmake.exe" -E make_directory /glad-build && echo Generating with args --out-path /glad-build --api gl:core=3.3 --reproducible c && C:\Users\alpha\AppData\Local\Programs\Python\Python311\python.exe -m glad --out-path /glad-build --api gl:core=3.3 --reproducible c && echo Writing /glad-build/args.txt && echo --out-path /glad-build --api gl:core=3.3 --reproducible c > /glad-build/args.txt"
der kommt beim Starten vom programm und nicht beim CMAKE ausführen?
Sieht aber aus wie eine fehlermeldung beim bauen und das bauen geschieht durch CMake.
Hm, blöd, hier ist der Pfad
C:\Users\alpha\3D Objects\backroomsC\cmake-build-debug\external\glad
statt
C:/Users/alpha/3D Objects/backroomsC/external/glad/cmake
Okay, mach mal die Ausgabe des Pfades in der CMakeList direkt vor
add_custom_command
Hier noch das davor falls du das auch brauchst
[0/21] glad_gl_core_33-generate
Cleaning /glad-build
Generating with args --out-path /glad-build --api gl:core=3.3 --reproducible c
Ah wobei, ich verstehe jetzt, wieso das so ist.
Ich bräuchte einmal den Baum des Build-Directories, insbesondere von external/glad, ich möchte sehen, ob das irgendwelche Dateien rüberkopiert.
C:/Users/alpha/3D Objects/backroomsC kommt dann einfach nur
Hm, okay, nicht was ich erwartet hatte, aber irrelevant, wenn das so funktioniert, wie ich denke.
Denn das Problem ist offenbar: Der macht das CD in das build dir, das Python liegt aber im src dir.
Kannst du mir mal zeigen, welche Dateien alle im build-dir liegen, insbesondere unter build/external/glad?
Okay, wie ich mir das dachte. Sieht nach einem Bug aus. Ich erstelle einen weiteren Issue im Github.
Über einen Workaround kann man dann nachdenken.
Ich habe den Issue erstellt, du musst das nicht tun.
Was du tun musst: versuch mal folgenden Hotfix:
In der CMakeList von glad folgendes ändern:
add_custom_command(
OUTPUT ${GLAD_FILES} ${GLAD_ARGS_PATH}
COMMAND echo Cleaning ${GLAD_DIR}
COMMAND ${CMAKE_COMMAND} -E remove_directory ${GLAD_DIR}
COMMAND ${CMAKE_COMMAND} -E make_directory ${GLAD_DIR}
COMMAND echo Generating with args ${GLAD_ARGS}
COMMAND ${PYTHON_EXECUTABLE} -m glad ${GLAD_ARGS}
COMMAND echo Writing ${GLAD_ARGS_PATH}
COMMAND echo ${GLAD_ARGS} > ${GLAD_ARGS_PATH}
WORKING_DIRECTORY ${GLAD_SOURCES_DIR}
COMMENT "${TARGET}-generate"
USES_TERMINAL
)
zu
add_custom_command(
OUTPUT ${GLAD_FILES} ${GLAD_ARGS_PATH}
COMMAND echo Copying ${GLAD_SOURCES_DIR}/glad
COMMAND ${CMAKE_COMMAND} -E copy
${GLAD_SOURCES_DIR}/glad
${CMAKE_CURRENT_BINARY_DIR}/external/glad
COMMAND echo Cleaning ${GLAD_DIR}
COMMAND ${CMAKE_COMMAND} -E remove_directory ${GLAD_DIR}
COMMAND ${CMAKE_COMMAND} -E make_directory ${GLAD_DIR}
COMMAND echo Generating with args ${GLAD_ARGS}
COMMAND ${PYTHON_EXECUTABLE} -m glad ${GLAD_ARGS}
COMMAND echo Writing ${GLAD_ARGS_PATH}
COMMAND echo ${GLAD_ARGS} > ${GLAD_ARGS_PATH}
WORKING_DIRECTORY ${GLAD_SOURCES_DIR}
COMMENT "${TARGET}-generate"
USES_TERMINAL
)
Ich hoffe das funktioniert (wenn nicht muss man evtl. noch etwas rumspielen.)
Den Bug habe ich dir bereits erklärt.
Bzw.:
file(RELATIVE_PATH GLAD_REL_DIR ${CMAKE_SOURCE_DIR} ${GLAD_SOURCES_DIR})
add_custom_command(
OUTPUT ${GLAD_FILES} ${GLAD_ARGS_PATH}
COMMAND echo Copying ${GLAD_SOURCES_DIR}/glad
COMMAND ${CMAKE_COMMAND} -E copy
${GLAD_SOURCES_DIR}/glad
${CMAKE_CURRENT_BINARY_DIR}/${GLAD_REL_DIR}/glad
COMMAND echo Cleaning ${GLAD_DIR}
COMMAND ${CMAKE_COMMAND} -E remove_directory ${GLAD_DIR}
COMMAND ${CMAKE_COMMAND} -E make_directory ${GLAD_DIR}
COMMAND echo Generating with args ${GLAD_ARGS}
COMMAND ${PYTHON_EXECUTABLE} -m glad ${GLAD_ARGS}
COMMAND echo Writing ${GLAD_ARGS_PATH}
COMMAND echo ${GLAD_ARGS} > ${GLAD_ARGS_PATH}
WORKING_DIRECTORY ${GLAD_SOURCES_DIR}
COMMENT "${TARGET}-generate"
USES_TERMINAL
)
Andere Fehler!
[0/21] glad_gl_core_33-generate
Copying external/glad/glad
Error copying file "external/glad/glad" to "C:/Users/alpha/3D Objects/backroomsC/cmake-build-debug/external/glad".
Ach okay, dann ändere das zu:
add_custom_command(
OUTPUT ${GLAD_FILES} ${GLAD_ARGS_PATH}
COMMAND echo Copying ${GLAD_SOURCES_DIR}/glad
COMMAND ${CMAKE_COMMAND} -E copy
${CMAKE_SOURCE_DIR}/${GLAD_SOURCES_DIR}/glad
${CMAKE_CURRENT_BINARY_DIR}/${GLAD_SOURCES_DIR}/glad
COMMAND echo Cleaning ${GLAD_DIR}
COMMAND ${CMAKE_COMMAND} -E remove_directory ${GLAD_DIR}
COMMAND ${CMAKE_COMMAND} -E make_directory ${GLAD_DIR}
COMMAND echo Generating with args ${GLAD_ARGS}
COMMAND ${PYTHON_EXECUTABLE} -m glad ${GLAD_ARGS}
COMMAND echo Writing ${GLAD_ARGS_PATH}
COMMAND echo ${GLAD_ARGS} > ${GLAD_ARGS_PATH}
WORKING_DIRECTORY ${GLAD_SOURCES_DIR}
COMMENT "${TARGET}-generate"
USES_TERMINAL
)
[0/21] glad_gl_core_33-generate
Copying external/glad/glad
Cleaning /glad-build
Generating with args --out-path /glad-build --api gl:core=3.3 --reproducible c
C:\Users\alpha\AppData\Local\Programs\Python\Python311\python.exe: No module named glad.__main__; 'glad' is a package and cannot be directly executed
:/
Uf... ganz viel rot XD
Traceback (most recent call last):
File "<frozen runpy>", line 198, in _run_module_as_main
File "<frozen runpy>", line 88, in _run_code
File "C:\Users\alpha\3D Objects\backroomsC\cmake-build-debug\external\glad\glad\__main__.py", line 17, in <module>
from glad.generator import GenerationInfo
File "C:\Users\alpha\3D Objects\backroomsC\cmake-build-debug\external\glad\glad\generator\__init__.py", line 7, in <module>
from jinja2 import Environment, ChoiceLoader, PackageLoader
ModuleNotFoundError: No module named 'jinja2'
Das geht einfach.
Command-Prompt aufmachen, dann
pip install Jinja2
Dann gegebenenfalls die IDE neustarten.
Oh man eine Rieseige Fehöermeldung... Also besser gesagt ganz viele kleine sowas hier zb:
/glad-build/src/gl.c:4920:54: error: expected ';' before 'load'
4920 | glad_glBinormal3ivEXT = (PFNGLBINORMAL3IVEXTPROC) load(userptr, "glBinormal3ivEXT");
| ^~~~~
| ;
/glad-build/src/gl.c:4921:29: error: 'PFNGLBINORMAL3SEXTPROC' undeclared (first use in this function); did you mean 'PFNGLNORMAL3SVPROC'?
4921 | glad_glBinormal3sEXT = (PFNGLBINORMAL3SEXTPROC) load(userptr, "glBinormal3sEXT");
| ^~~~~~~~~~~~~~~~~~~~~~
| PFNGLNORMAL3SVPROC
Sind alle ca. so aufgebaut
Hm, okay, die brauchen die OpenGL-Header.
"glext.h" fehlt anscheinend.
Muss man offenbar selbst extra installieren:
https://stackoverflow.com/questions/3933027/how-to-get-the-gl-library-headers
https://github.com/KhronosGroup/OpenGL-Registry
Schau am besten, wo dein GL-Directioy ist.
Bzw. besser vielleicht, direkt glut zu installieren:
https://www.opengl.org/resources/libraries/glut/glut_downloads.php
Evtl. ist das auch schon installiert, dann reicht:
find_package(GLUT REQUIRED)
include_directories(${OPENGL_INCLUDE_DIRS} ${GLUT_INCLUDE_DIRS})
und
target_link_libraries(backR glad_gl_core_33 ${GLFW3_LIBRARY} glfw ${OPENGL_LIBRARIES} ${GLUT_LIBRARY})
Kannst du mir vielleicht direkt den link zum download von glut geben? Finde die seite sehr unübersichtlich
Ich vermute folgende:
https://www.opengl.org/resources/libraries/glut/glut37.zip
aber keine Ahnung. Vielleicht brauchst du das auch gar nicht installieren und es klappt auch so.
Schau auch mal erst hier:
https://w3.cs.jmu.edu/bernstdh/web/common/help/cpp_mingw-glut-setup.php
mach am besten das und wenn es nicht geht, dann lad dir lieber die Header direkt runter und platziere sie im passendem Include-Directory von MinGW.
Ich verstehe nicht wo ich die lib und die dll hinlegen muss
Hier steht etwas dazu:
https://web.cs.wpi.edu/~gogo/courses/mingw/
Aber versuch es ersteinmal ohne die Libraries und schau, ob du denselben Fehler bekommst. Wenn ja, dann lohnt sich das sowieso nicht.
Schon beim cmake reload
CMake Error at C:/Program Files/JetBrains/CLion 2022.2.4/bin/cmake/win/share/cmake-3.23/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find GLUT (missing: GLUT_glut_LIBRARY)
Der Fehler kommt aus einer anderen cmake file!
CMake Error at C:/Program Files/JetBrains/CLion 2022.2.4/bin/cmake/win/share/cmake-3.23/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find GLUT (missing: GLUT_glut_LIBRARY)
Da steht nähmlich:
if (${_NAME}_FIND_REQUIRED)
message(FATAL_ERROR "${__msg}")
Das ist schon klar, aber wir indcluden ja GLUT in unserer CMakeList obwohl wir das gar nicht verwenden, also lassen wir das einfach.
Okay, dann lädst du dir die OpenGL-Header runter und packst sie dahin, wo du auch den GLUT-Header gepackt hast.
Welche Header das sind stand hier:
https://stackoverflow.com/questions/3933027/how-to-get-the-gl-library-headers
Hä habe ich die header nicht schon?
Da ist der gl.h glaux.g glcodearb.h glext.h glu.h glut.h glxext.h gwl.h wglext.h drinn
Die sind da schon drinnen? Okay, dann ist es komisch, dass der Fehler auftritt.
Dann printe dir mal
${OPENGL_INCLUDE_DIRS}
aus und schau, ob das dasselbe Verzeichnis ist. Wenn nicht, dann kopierst du die Files in das Verzeichnis, das ausgegeben wurde.
Hä?!
CMake Error at CMakeLists.txt:31 (message):
message called with incorrect number of arguments
einfach mit
message("${OPENGL_INCLUDE_DIRS}")
Hm, okay, das ist blöd...und erklärt den fehler.
Die Variable ist offenbar leer.
Dann mach mal aus
include_directories(${OPENGL_INCLUDE_DIRS})
folgendes:
include_directories(${OPENGL_INCLUDE_DIR})
und für's debugging printest du das auch noch einmal aus damit wir sehen, ob es jetzt geht.
Hm ja, das sollte gehen:
Ist auch leermessage(WARNING "${OPENGL_INCLUDE_DIR}")
CMake Warning at CMakeLists.txt:31 (message):
Pack das hier mal unter das find OPENGL:
if(NOT OPENGL_FOUND)
message(ERROR "OPENGL not found!")
endif(NOT OPENGL_FOUND)
Das printed einen Fehler, wenn das Include-Dir nicht existiert. Offenbar ist das unter MinGW so. Lösung müsste man noch finden, aber nicht jetzt/heute, dafür ist es mir jetzt zu spät.
Achso, dann pack das hier noch darunter:
if(OPENGL_INCLUDE_DIR STREQUAL "")
message(ERROR "OPENGL_INCLUDE_DIR is empty!")
endif(OPENGL_INCLUDE_DIR STREQUAL "")
Komisch. Aber können wir uns morgen drum kümmern. Oder du schaust, selbst woran das liegt.
Ich versuch es ja aber ich habe keine ahnung davon
Googel ist dein Freund. Und der "message"-Befehl, der dir dagt, was in der Variable steht (wenn die nicht leer ist, dann vielleicht mit Whitespaces gefüllt?).
Du kannst auch mal GL/gl.h in deinem eigenem programm includen und das Bauen von GLAD deaktivieren und schauen, ob der die Header findet. Dann wüsste man, ob die Header generell nicht verfügbar sind oder nur beim Bauen von GLAD nicht.
Ich habe grade nur ein hello world programm in der datei stehen also garnichts includet
Und dann einmal GLAD aus der CMAkeList rausnehmen und schauen, opb es dir da auch einen Fehler wirft.
Wenn nicht, dann hat nur GLAD ein Problem mit dem includen.
Sobald das getan ist: Zu dem Bug den ich gestern gemeldet habe gab es eine Antwort. Offenbar ist das Problem das wird das Source-Directory relativ angegeben haben, das können wir dann später einmal fixen.
Okay, das ist mal etwas.
Dann bau GLAD wieder ein und mach da auch die Änderungen din der CMakeList rückgängig (lad dir die notfalls neu runter).
Dann änderst du in unserer CMake List folgende Zeile
set(GLAD_SOURCES_DIR "external/glad")
zu
set(GLAD_SOURCES_DIR "${CMAKE_SOURCE_DIR}external/glad")
Das sollte den Fehler, für den wir ein Workaround gebaut hatten, beheben, vielleicht behebt es auch noch die anderen Fehler.
mhm
CMake Error at CMakeLists.txt:34 (add_subdirectory):
add_subdirectory given source "C:/Users/alpha/3D
Objects/backroomsCexternal/glad/cmake" which is not an existing directory.
meinst du vielleicht ein / vor external?
So baut es ich mache jetzt mal das hello world programm weg
Jaa es klappt :D habe jetzt ein Blaues Fenster! danke! Ich hoffe das wars dann!
Zumindfst erstmal... ich werde bestimmt wieder ein problem haben wenn ich noch eine lib brauche
Okay, sehr gut!
Warum fängst du eigentlich direkt mit Graphik-Programmierung an? Oder hast du schon Programmiererfahrung?
Jap ich habe Java gemacht und da mit libgdx gearbeitet (natives framework von openGL) aber ich musste wächseln weil es kein shadowpoint light gab!
Ich habe damals mit LWJGL angefangen, erst OpenGL, später dnan Vulkan und als in der Uni dann C++ darnkam hab ich da auch hin gewechselt aber bisher noch kaum eigenes Zeug implementiert, da mir die Zeit fehlt. Bzw. nur Zeug, das auf existierendem aufbaut und einen Vulkan-Helper, der aber noch in der Anfangsphase ist.
Kann es sein das ich noch etwas brauche namens assimp? XD
Assimp ist ein Model-Loader. Gibt aber bessere als den (assimp ist nicht toll zu nutzen).
In einer Vorlesung wurden CGAL, OpenMesh und MPM genannt, die habe ich mir aber noch nicht angeschaut.
Also ich meine um Blender zu importieren
Und in vielen videos sehe ich den link https://learnopen.gl/
aber den gibt es garnicht?
Gemeint ist wohl:
Um Files von Blender zu importieren gibt es viele Möglichkeiten. Such dir einen Mldel-Loader aus und arbeite damit.
In welchem File-Format du exportierst musst du sehen. OBJ funktioniert recht einfach und auf vielen Plattformen (kann man auch leicht selbser einen Loader für schreiben), es fehlen aber ein paar Features.
Collada hat mehr Features, ist aber echt kaputt (hatte mal versucht einen Loader dafür zu schreiben. Die Spezifikation ist Kacke). Dann eher FBX oder evtl. noch etwas anderes.
Funktionieren schatten also ich glaube shader mit allen model loadern?
Du kannst Schatten auch ganz ohne Model-Loader implementieren. Der läd ja nur die Modelle, das hat ja erst einmal nichts mit Schatten zu tun.
Ja aber das licht muss ja irgendwo hängen bleiben und vielleicht weiß er es dann ja nicht war meine idee
Das Licht ist erst einmal nicht vorhanden, das musst du dir selber implementieren. Bzw. es kann schon sein, dass dir der Model-Loader auch Lichtquellen mit diversen Eigenschaften zurückliefert, aber du hast dann nur so Informationen wie Art der Lichtquelle, Position, richtung, Farbe, ... und muss selber dafür sorgen, dass dann entsprechende Beleuchtung stattfindet.
Ich denke das LearnOpenGL-Tutorial ist da schon gut für den Anfang.
Warte mal... ich dachte ich hätte glut installiert jetzt?
Wobei wir glut auch nur den header irgendwo reingeschoben haben. Wenn es nicht linkt müsstest du die Libraries auch noch passend platzieren.
Hallo 😅 2 Tage ists her...
Glad ill irgendwie nicht:
Er sagt ganz oft das er Funktionen redefined hat! so wie warning: "__gl_h_" redefined
33 | #define __gl_h_ 1
|
Und am Ende sagt er C:/Users/alpha/3D Objects/backroomsC/main.cpp:379: undefined reference to `gladLoadGL'
Und wenn du das "gladLoadGL" rausnimmst? Vielleicht ist das schon geladen und du versuchst es noch einmal zu laden?
Aber keine Ahnung.
Reicht schon beim includen der header. Dann kommen schon die fehler
Ahh in der CMakeList war das bei target link libraries nicht drinne! Aber wenn ich es hinzufüge sagt er er kann es nicht rüber kopieren
Das hat nichts mit Libraries zu tun. das passiert, da irgendwo ein header doppelt includet wird und der aus welchen Gründen auch immer kein include-Guard hat.
Vielleicht liegt es an dem glut.h das wir manuell hinzugefügt hatten. Wenn du das aus dem ordner, wo du es reingelegt hast, löschst, vielleicht geht es dann?
Ansonsten bräuchte man die ganze Fehlermeldung, die sollte einem nämlich auch sagen, wo die Sachen definiert wurden.
Habe den glut.h jetzt au den desktop verschoben aber geht immer noch nicht. Hier die ganze Fehlermeldung:
[0/22] glad_gl_core_33-generate
Copying "C:/Users/alpha/3D Objects/backroomsC/external/glad/glad"
Error copying directory from "C:/Users/alpha/3D Objects/backroomsC/C:/Users/alpha/3D Objects/backroomsC/external/glad/glad" to "C:/Users/alpha/3D Objects/backroomsC/cmake-build-debug/C:/Users/alpha/3D Objects/backroomsC/external/glad/glad".
FAILED: /glad-build/include/KHR/khrplatform.h /glad-build/include/glad/gl.h /glad-build/src/gl.c /glad-build/args.txt
cmd.exe /C "cd /D "C:\Users\alpha\3D Objects\backroomsC\external\glad" && echo Copying "C:/Users/alpha/3D Objects/backroomsC/external/glad/glad" && "C:\Program Files\JetBrains\CLion 2022.2.4\bin\cmake\win\bin\cmake.exe" -E copy_directory "C:/Users/alpha/3D Objects/backroomsC/C:/Users/alpha/3D Objects/backroomsC/external/glad/glad" "C:/Users/alpha/3D Objects/backroomsC/cmake-build-debug/C:/Users/alpha/3D Objects/backroomsC/external/glad/glad" && echo Cleaning /glad-build && "C:\Program Files\JetBrains\CLion 2022.2.4\bin\cmake\win\bin\cmake.exe" -E remove_directory /glad-build && "C:\Program Files\JetBrains\CLion 2022.2.4\bin\cmake\win\bin\cmake.exe" -E make_directory /glad-build && echo Generating with args --out-path /glad-build --api gl:core=3.3 --reproducible c && C:\Users\alpha\AppData\Local\Programs\Python\Python311\python.exe -m glad --out-path /glad-build --api gl:core=3.3 --reproducible c && echo Writing /glad-build/args.txt && echo --out-path /glad-build --api gl:core=3.3 --reproducible c > /glad-build/args.txt"
Ich dachte du hättest die CMake von GLAD wieder zur Originalen ausgetauscht. Das hier ist die modifizierte Version und die geht mit dem absolutem Pfad nicht.
Wie meinst du? Ich habe
glad_gl_core_33
bei target link libs gestern erst wieder reingemacht weil ich dachte das hilft falls du das meinst
ich meine folgenden Kommentar meinerseits:
Okay, das ist mal etwas.
Dann bau GLAD wieder ein und mach da auch die Änderungen din der CMakeList rückgängig (lad dir die notfalls neu runter).
Dann änderst du in unserer CMake List folgende Zeile
set(GLAD_SOURCES_DIR "external/glad")
zu
set(GLAD_SOURCES_DIR "${CMAKE_SOURCE_DIR}external/glad")
Das sollte den Fehler, für den wir ein Workaround gebaut hatten, beheben, vielleicht behebt es auch noch die anderen Fehler.
Ahh okay ich dachte du meintest nur das was ich in den letzten paar nachrichten hinzugefügt gabe!
Ahh achso du meinst die CMake ist von GLAD
Okay habe jetzt ist zwar ein error mehr da aber er sagt so 1000 mal das er etwas redifined
erstes:
/glad-build/src/gl.c:4905:72: error: expected ';' before 'load'
4905 | glad_glGetConvolutionFilterEXT = (PFNGLGETCONVOLUTIONFILTEREXTPROC) load(userptr, "glGetConvolutionFilterEXT");
| ^~~~~
| ;
Ist nicht ganz das erste weil hier die console endet (zu viel text)
Und am ende stop ninja
Die Message ist kein redefine. Gib mir bitte eine ganze Fehlermeldung. Wenn da etwas redefined wurde, dann müsste da stehen, wo das zuerst definiert wurde und wo es dann erneut defibniert wurde.
Es gibt halt keine Fehlermeldung... So endet es:
| PFNGLTEXCOORD4FVPROC
/glad-build/src/gl.c:6890:70: error: expected ';' before 'load'
6890 | glad_glTexCoord4fVertex4fvSUN = (PFNGLTEXCOORD4FVERTEX4FVSUNPROC) load(userptr, "glTexCoord4fVertex4fvSUN");
| ^~~~~
| ;
/glad-build/src/gl.c: In function 'gladLoadGL':
/glad-build/src/gl.c:7999:31: warning: passing argument 1 of 'gladLoadGLUserPtr' from incompatible pointer type [-Wincompatible-pointer-types]
7999 | return gladLoadGLUserPtr( glad_gl_get_proc_from_userptr, GLAD_GNUC_EXTENSION (void*) load);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| void (* (*)(void *, const char *))(void)
/glad-build/src/gl.c:7662:44: note: expected 'GLADuserptrloadfunc' {aka 'void (* (*)(const char *, void *))(void)'} but argument is of type 'void (* (*)(void *, const char *))(void)'
7662 | int gladLoadGLUserPtr( GLADuserptrloadfunc load, void *userptr) {
| ~~~~~~~~~~~~~~~~~~~~^~~~
ninja: build stopped: subcommand failed.
Also es gibt errors aber nicht rot mackierT:
| PFNGLTEXCOORD4FVPROC
/glad-build/src/gl.c:6890:70: error: expected ';' before 'load'
6890 | glad_glTexCoord4fVertex4fvSUN = (PFNGLTEXCOORD4FVERTEX4FVSUNPROC) load(userptr, "glTexCoord4fVertex4fvSUN");
|
Schau mal, ob du irgendwie den Anfang des ganzen bekommst, mit dem Ende kann man wenig anfangen.
Irgendetwas ist da grundlegend kaputt und was das ist steht zumeist am Anfang.
Evtl. kann man erast ein "clr" oder "clear" auf die Konsole machen oder die Konsole größer machen.
Hm... ich sehe keine möglichkeit die CLion console größer zu machen
Dann darin scrollen? Oder in den Einstellungen? Oder den Output woanders rausschreiben lassen?
Aber wie? Das mit dem CMD hat ja nicht so gut geklappt... das haben wir ja schon probiert und wenn ich den command den CLion benutzt in dem cmd laufen lasse wird das trortzdem in clion geschrieben
Was weiß ich, ich nutze kein CLion. Du hast das vor dir und du hast Internet, irgendwie wird das gehen.
Ich google auch noch mal, aber deren Seite läuft nicht ordentlich.
https://www.jetbrains.com/help/clion/settings-console-folding.html
"Override console cycle buffer size" ausschalten.
Ahja :D danke habe ich nicht gefunden weis nicht wie man das nennt...
Am anfang steht das
[1/3] Building C object CMakeFiles/glad_gl_core_33.dir/glad-build/src/gl.c.obj
FAILED: CMakeFiles/glad_gl_core_33.dir/glad-build/src/gl.c.obj
C:\msys64\mingw64\bin\cc.exe -I"C:/Users/alpha/3D Objects/backroomsC/external/glfw-3.3.8/include" -I"C:/Users/alpha/3D Objects/backroomsC/external/glfw-3.3.8/deps" -I/glad-build/include -g -MD -MT CMakeFiles/glad_gl_core_33.dir/glad-build/src/gl.c.obj -MF CMakeFiles\glad_gl_core_33.dir\glad-build\src\gl.c.obj.d -o CMakeFiles/glad_gl_core_33.dir/glad-build/src/gl.c.obj -c /glad-build/src/gl.c
/glad-build/src/gl.c:658:1: error: unknown type name 'PFNGLACCUMXOESPROC'; did you mean 'PFNGLACCUMPROC'?
658 | PFNGLACCUMXOESPROC glad_glAccumxOES = NULL;
| ^~~~~~~~~~~~~~~~~~
| PFNGLACCUMPROC
/glad-build/src/gl.c:658:39: warning: initialization of 'int' from 'void *' makes integer from pointer without a cast [-Wint-conversion]
658 | PFNGLACCUMXOESPROC glad_glAccumxOES = NULL;
| ^~~~
Ich kann jetzt nicht durch die ganze konsole scrollen und nach errors suchen weil das ziemlich viele Zeilen sind
Das sieht schon besser aus.
Das ist dann der Fehler, den wir vorhin auch schon hatten, dass glext.h nicht gefunden wird.
Schau mal unter
C:\msys64\mingw64\include
ob sich da die OpenGL-Header im Unterverzeichnis "GL" befinden.
Wenn nicht, dann kopier dir die von da rüber, wo du sie das letzte mal gefunden hattest.
Mintest du include/GL ? glext.h ist drinn aber ich habe glut grade rausgenommen meintest du ja
Bitte sag mir den ganzen Pfad und welche Dateien darin liegen.
Schau mal ob in einer der Dateien der Typ
PFNGLACCUMXOESPROC
definiert wird.
Müsste eigentlich geschehen.
Gut, das war zu erwarten, das passt also.
Führ mal folgendes Command aus:
C:\msys64\mingw64\bin\cc.exe -xc++ -E -v -
Das sollte uns dann ausgeben, welche Ordner vom gcc includet werden.
Ganz schön viel text:
C:\Windows\system32>C:\msys64\mingw64\bin\cc.exe -xc++ -E -v -
Using built-in specs.
COLLECT_GCC=C:\msys64\mingw64\bin\cc.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-12.2.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/include --libexecdir=/mingw64/lib --enable-bootstrap --enable-checking=release --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,jit --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts --enable-libstdcxx-time --disable-libstdcxx-pch --enable-lto --enable-libgomp --disable-multilib --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev1, Built by MSYS2 project' --with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as --with-gnu-ld --disable-libstdcxx-debug --with-boot-ldflags=-static-libstdc++ --with-stage1-ldflags=-static-libstdc++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Rev1, Built by MSYS2 project)
COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=generic' '-march=x86-64'
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/cc1plus.exe -E -quiet -v -iprefix C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/ -D_REENTRANT - -mtune=generic -march=x86-64 -dumpbase -
ignoring nonexistent directory "C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/include"
ignoring duplicate directory "C:/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../include/c++/12.2.0"
ignoring duplicate directory "C:/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../include/c++/12.2.0/x86_64-w64-mingw32"
ignoring duplicate directory "C:/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../include/c++/12.2.0/backward"
ignoring duplicate directory "C:/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/12.2.0/include"
ignoring nonexistent directory "D:/a/msys64/mingw64/include"
ignoring nonexistent directory "/mingw64/include"
ignoring duplicate directory "C:/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/12.2.0/include-fixed"
ignoring nonexistent directory "C:/msys64/mingw64/lib/gcc/../../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/include"
ignoring nonexistent directory "D:/a/msys64/mingw64/include"
#include "..." search starts here:
#include <...> search starts here:
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../include/c++/12.2.0
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../include/c++/12.2.0/x86_64-w64-mingw32
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../include/c++/12.2.0/backward
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/include
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../include
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/include-fixed
End of search list.
Hm, unser Include-Dir ist dabei
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../include
Das entspricht
C:/msys64/mingw64/include
Dann ist jetzt die Frage, warum zur Hölle GLAD das nicht findet.
Schau dir mal
/glad-build/src/gl.c
welche Dateien das includet.
Hm mir fällt grade auf es gibt kein glad/gl.h nur GL/gl.h aber in clion include ich das glad/gl.h wie auch immer:
#include <windows.h>
#include <stddef.h>
Ich lese das grade alles über explorer und editor ab nicht über CLion
Doch, es gibt ein glad/gl.h Im Zweifelsfalle liegt das im Build-Ordner.
Ah ja genau da ist es. Da sehe ich garkeine includes. Ah doch wenn man ganz weit runterscrollt
#include <KHR/khrplatform.h>
#ifdef GLAD_INTERNAL_HAVE_WINAPIFAMILY
#include <winapifamily.h>
und das wars dann
Ganz unten? Okay.
Waren in der gl.c evtl. noch irgendwelche Includes versteckt (weiter unten)?
Ne nicht ganz unten der KHR ist so bei der hälfte und der winapifamily so bei einem viertel
In gl.c im glad-build ordner
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <glad/gl.h>
Hm, okay. Dann Schreib mir noch einmal den Inhalt deiner CMakeList.txt auf, dann eröffne ich einen neuen Issue in Github-Repro.
Keine Ahnung, wieso das nicht geht.
Okay :)
cmake_minimum_required(VERSION 3.23)
set(PROJECT_NAME backroomsC)
project(${PROJECT_NAME})
add_executable(${PROJECT_NAME} main.cpp util/List.h util/List.cpp)
set(SOURCE_FILES main.cpp) # welche Dateien kompiliert werden sollen
#set(ENV{PYTHONPATH} ENV{PYTHONPATH}":${GLAD_SOURCES_DIR}")
set(GLFW_SOURCE_DIR "external/glfw-3.3.8/src")
set(GLAD_SOURCES_DIR "${CMAKE_SOURCE_DIR}/external/glad")
set(GLFW_LIBRARY_TYPE STATIC)
set(GLFW_BUILD_EXAMPLES OFF)
set(GLFW_BUILD_TESTS OFF)
set(GLFW_BUILD_DOCS OFF)
set(GLFW_INSTALL OFF)
set(CMAKE_STATIC_LIBRARY_SUFFIX ".lib")
set(CMAKE_SHARED_LIBRARY_SUFFIX ".dll")
find_package(OpenGL REQUIRED)
if(NOT OPENGL_FOUND)
message(ERROR "OPENGL not found!")
endif(NOT OPENGL_FOUND)
if(OPENGL_INCLUDE_DIR STREQUAL "")
message(ERROR "OPENGL_INCLUDE_DIR is empty!")
endif(OPENGL_INCLUDE_DIR STREQUAL "")
include_directories(${OPENGL_INCLUDE_DIRS})
add_subdirectory(external/glfw-3.3.8)
include_directories(${OPENGL_INCLUDE_DIR})
include_directories(external/glfw-3.3.8/include external/glfw-3.3.8/deps)
add_subdirectory("${GLAD_SOURCES_DIR}/cmake")
glad_add_library(glad_gl_core_33 REPRODUCIBLE LOCATION "/glad-build" API gl:core=3.3)
target_link_libraries(${PROJECT_NAME} glad_gl_core_33 ${GLFW3_LIBRARY} glfw ${OPENGL_LIBRARIES})
Am Anfang deines eigenen Source-Codes schau mal, dass der Include von "glad/gl.h" vor dem Include von glfw steht.
Läuft aufs selbe raus
FAILED: CMakeFiles/glad_gl_core_33.dir/glad-build/src/gl.c.obj
C:\msys64\mingw64\bin\cc.exe -I"C:/Users/alpha/3D Objects/backroomsC/external/glfw-3.3.8/include" -I"C:/Users/alpha/3D Objects/backroomsC/external/glfw-3.3.8/deps" -I/glad-build/include -g -MD -MT CMakeFiles/glad_gl_core_33.dir/glad-build/src/gl.c.obj -MF CMakeFiles\glad_gl_core_33.dir\glad-build\src\gl.c.obj.d -o CMakeFiles/glad_gl_core_33.dir/glad-build/src/gl.c.obj -c /glad-build/src/gl.c
auch alles neu defined und so
und unknown tyope
Dann mach mal aus folgendem:
add_subdirectory(external/glfw-3.3.8)
include_directories(${OPENGL_INCLUDE_DIR})
include_directories(external/glfw-3.3.8/include external/glfw-3.3.8/deps)
add_subdirectory("${GLAD_SOURCES_DIR}/cmake")
glad_add_library(glad_gl_core_33 REPRODUCIBLE LOCATION "/glad-build" API gl:core=3.3)
target_link_libraries(${PROJECT_NAME} glad_gl_core_33 ${GLFW3_LIBRARY} glfw ${OPENGL_LIBRARIES})
folgendes:
add_subdirectory("${GLAD_SOURCES_DIR}/cmake")
glad_add_library(glad_gl_core_33 REPRODUCIBLE LOCATION "/glad-build" API gl:core=3.3)
add_subdirectory(external/glfw-3.3.8)
include_directories(${OPENGL_INCLUDE_DIR})
include_directories(external/glfw-3.3.8/include external/glfw-3.3.8/deps)
target_link_libraries(${PROJECT_NAME} glad_gl_core_33 ${GLFW3_LIBRARY} glfw ${OPENGL_LIBRARIES})
Ja... also naja wenn ich es include schmiert das Fenster sofort ab... also wird weiß und wenn ich es nicht include klappt es
Solange es baut ist das schon ein Fortschritt. Für das sofortige abschmieren müsste man noch eine andere Lösung finden (bzw. erst einmal einen Error-handler einbauen oder soetwas).
Also es baut wenn du includest?
Guten Tag. Ich hab e gleich zwei probleme! Ich brauche jetzt noch eine Lib und wie es die anderen machen klappt es bei mir natürlich auch mal wieder nicht! Und zweitens finde ich keine lösung dazu wie man methoden von einem namespace von einer header file in einer cpp file difinieren kann!
Erstmal zu der lib. Ich brauche die assimp lib zum inport von 3D models! Wenn ich es in dem cmake -gui.exe mache wie es alle machen kommt der fehler das er den compiler nicht finden konnte. Der genau error ist:
Das System kann die angegebene Datei nicht finden
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
Da es so ähnlich wie die anderen libs aufgebaut ist habe ich es in der cmakelist.txt versucht mit
set(ASSETS_SOURCE_DIR assets)
set(ASSETS_DEST_DIR cmake-build-debug)
include_directories(external/glfw-3.3.8/include external/glfw-3.3.8/deps external/assimp/include)
target_link_libraries(${PROJECT_NAME} ${ASSIMP_LIBRARIES})
Da kommt dann aber
undefined reference to `aiImportFile'.
Zum zweiten problem komme ich dann später. Wäre nett wenn sie mir noch einmal aushelfen würden :)
Schreib mir hier noch einmal einen Kommentar, dann schaue ich, dass ich mir das die nächsten Tage einmal anschaue.
Ansonsten kannst du derweilen mal irgendetwas mit "findPackage" oder so versuchen oder online nach Beispielen suchen.
So wie ich find package versucht habe hat er es nicht gefunden und online hat niemand anders das problem...Die haben dann einfach vergessen den compiler in die umgebungs variablen zu setzetn zb.
Pack Assimp in ein Directory wie vorher die anderen Libraries auch und include das Subdirectory in deinem CMake-File. Zudem fügst du Include- und Library-Directory hinzu.
Folgende Konfiguration:
set(BUILD_SHARED_LIBS OFF);
set(ASSIMP_BUILD_ASSIMP_TOOLS OFF);
set(ASSIMP_BUILD_SAMPLES OFF);
set(ASSIMP_BUILD_TESTS OFF);
set(ASSIMP_INSTALL OFF);
Hallo, Ich habe es vielleicht schon geschafft aber das zweite problem lässt es mich nicht ausprobieren... multiple definition von allen funktionen in einer header file. Am anfang steht halt
#ifndef BACKROOMS_GLFWUTILS_H
#define BACKROOMS_GLFWUTILS_H
und am ende
#endif
Trotzdem passiert das. Ist das problem weg wenn ich alles in einer cpp file definiere?
Ich frage lieber vorher weil das echt viele funktionen sind die ich gemacht habe.
Manches kannst du nicht in einem .cpp-File definieren, sondern musst das im Header machen.
So Dinge wie "inline" können dann helfen, das Problem zu beheben.
Folgender Link erklärt manche Probleme, die auftreten können:
Es ist ja nicht nur das die methoden doppelt deffiniert werden... auch die variablen! Ich dachte man soll die in der header file machen... Ach ich verstehe nichtmal mehr die errors! Hier mal ein beispiel:
c:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/backrooms.dir/sources/glfwUtils.cpp.obj:glfwUtils.cpp:(.bss+0x8): multiple definition of `glfw::mainWindow'; CMakeFiles/backrooms.dir/main.cpp.obj:c:/mingw64/include/c++/12.2.0/bits/stl_vector.h:312: first defined here
Was hat jetzt vector damit zu tun? Und warum soll da etwas mit glfw::mainWindow defined sein?
Window mainWindow = nullptr;
Und hier noch eins mit vectoren
c:/mingw64/include/c++/12.2.0/bits/stl_vector.h:100: multiple definition of `glfw::mainWindow'; CMakeFiles/backrooms.dir/main.cpp.obj:c:/mingw64/include/c++/12.2.0/bits/stl_vector.h:312: first defined here
Ja gut ich musste nur alles in die herder file machen.
Jetzt geht alles vielleicht. Allerdings braucht es wirklich 10 Minuten zum bauen! Ich habe gelesen das ich die dynamisch linken muss. Allerdings haben wir das ja ausgeschaltet. Ich finde im internett auch keine hilfe dazu. Ich habe jetzt mal wie aus dem internett versucht und er baut seit 30 min...
Es ist ja nicht nur das die methoden doppelt deffiniert werden... auch die variablen!
Selbes Problem. Der Include-Guard funktioniert nur jeweils für einen Build-Prozess. Wenn jetzt aber Dateien aus verschiedenen Build-Prozessen denselben Header includen, dann kommt es zu Problemen.
Variablen würde man entsprechend als "extern" deklarieren und dann in einem CPP-File definieren.
Was hat jetzt vector damit zu tun?
Ich vermute irgendwo wird ein Vector mit dem Typ als Template-Parameter verwendet.
Und warum soll da etwas mit glfw::mainWindow defined sein?
Offenbar existiert eine Variable "mainWindow" im Namespace "glfw", welche mehrfach definiert wird.
Ich vermute, irgendwo wurde der Header vergessen zu includen oder eine Forward-Declaration übersehen oder soetwas.
Allerdings braucht es wirklich 10 Minuten zum bauen!
Ja, das wird vermutlich an irgendwelchen komplizierten Templates oder so liegen. Solche kann man evtl. vereinfachen.
Dynamisch Linken bringt nur bedingt etwas. Also ja, das kann helfen, aber das muss man auch erst zum Laufen bringen.
Du müsstest "SHARED_LIBS" aktivieren und "SHARED" als Build-Type setzen, wo du das möchtest.
Im Endeffekt macht das dann aber womöglich dein Programm langsamer.
Jo ich habe alle functionen in einer header datei definiert. Ich meine es ging vorher wirklich nicht! Und das glfw::mainWindow habe ich als inline deklariet jetzt.
Meinst du damit es schneller läuft etwas in meinem code verändern oder in dem von assimp?
Es läd ja immerhin... Allerdings ist alles zielich verbugt mit dem program was ich geschrieben habe zum lesen der datei. Wenn du lust und Zeit und schonmal mit assimp gearbeitet hast könntest du drüber schauen?
Und Frohen neues :)
Meinst du damit es schneller läuft etwas in meinem code verändern oder in dem von assimp?
Lässt sich nicht allgemein sagen. Hängt halt davon ab, was genau das Bauen verlangsamt.
Wenn du lust und Zeit und schonmal mit assimp gearbeitet hast könntest du drüber schauen?
Assimp ist eine Qual, also nein. Wobei Assimp sogar noch besser ist als manch anderes, aber dennoch will man das eigentlich nicht verwenden, zu viele Sachen, die nicht klar dokumentiert sind und so.
Allerdings ist alles zielich verbugt mit dem program was ich geschrieben habe zum lesen der datei.
Kannst du das genauer ausführen?
Jo hier sind die bilder:
Erst wie es sein soll (in blender) und dann wie es jetzt ist (in glfw)
https://workupload.com/archive/P3PtuBPx
Wenn man e snicht gut erkennt, es ist schwarz weiß und falsch formatiert
Hm, ja genau, der Texture-Stack in Assimp war mit das hässlichste. Da musst du vermutlich etwas rumprobieren, bis das geht.
Ich kriege halt die tex:uv von einem vertex so
try {
auto tex_uvp = mesh->mTextureCoords[0];
if (tex_uvp != nullptr)
tex_uv = tex_uvp[j];
else
textureNull = false;
} catch (...) {print("vertex doesnt not contain attribut: tex_uv")textureNull = false;}
Und die textur einfach mit aigetTexture
Ich brauche nur den path und den typ. Die textur klasse kommt von dem tutorial von victor
Weiß jetzt nicht was ich so verändern kann
Und was auch komisch ist ich musste cuddling mode auf CCW umstellen. Vorher war es auf CW
Lies dir die Assimp-Spezifikation durch. Da steht bisschen etwas dazu drinnen, wie du aus dem texture-Stack deine Texturen bekommst.
Bzw. kann es auch schon einmal hilfreich sein, sich den Texture-Stack ausgeben zu lassen, dann siehst du vielleicht, wo es hakt (evtl. Operationen des Stacks nicht ausgeführt oder falsches Format für die texture verwendet oder sonstiges).
By the way: Du solltest If-Anweisungen nur mit geschweiften Klammern verwenden der Wartbarkeit wegen.
Oh und in welcher Sprache programmierst du? Sieht nicht nach C++ aus.
ja doch ist c++ aber print ist #define print(message) std::cout << message << std::endl;
Und was ist der texture stack? Der path zur texture ist korrekt! Also das kann es ja schon nicht sein denke ich
Der TextureStack ist das, was Assimp dir für die Textur zur Beschreibung des Materials gibt:
Achso ja aber ich entnehme ja nur den texture path und die tex_uv. DIeses mappinng und so brauch ich noch garnicht
Das weißt du nicht sicher. Hängt davon ab, wie das in der Model-Datei gespeichert ist und wie Assimp dir das präsentiert.
Deshalb würde ich den Stack auch zuerst ausprinten um zu schauen, ob eben das der Fall ist.
Muss ichjetzt jedes einzelne item kriegen oder gibt es eine funktion die mir einen string über alles ausgibt? Schätze das aireturn ist es nicht
Ich meine man musste sich da selber eine Funktion schreiben. Aber vielleicht hat das im Internet auch schon jemand für dich gemacht.
Ich könnte dir höchstens eine Java-Version davon geben.
Ist doch dann in lwjgl und nicht in assimp oder?
Ohhh kann sein das ich
aiGetMaterialUVTransform
brauch weil ich hab in dem blender project mit den vector was verschoben
Aber ergibt trotzdem keinen sinn das die textur grau ist.
Habe zwar kein ambient angegeben aber diffuse sollte doch gehen oder?
Ich kenne deinen TextureStack nicht. Wie gesagt, schau dir den an (evtl. mit einem Debugger zuerst) und schau, ob da was draufliegt, was du nicht beachtet hast.
Fehler können natürlich auch an anderer Stelle liegen.
Ich verstehe halt auch den code von dem tutorial nicht ganz... Da hat er JSON benutzt. Aber der code ist so durch einander das ich nicht weiß wie er funktioniert. Darum konnte ich ihn uch nicht erweitern. Mein model konnte es nicht laden. Jetzt muss ich halt auch mit der mesh klasse und allen anderen klassen von ihm weiter arbeiten und kann kein anderes tutorial irgendwie mit einbringen ohne es umzucshreiben. Aber soviel ich sehen kann hat er auch nur diffuse, specular texture und die Vevor normals, tex_uv, color un position und die indiceis aus der file entnommen. Was auch komisch ist:
https://workupload.com/file/LtN6ycQbjLd
So sieht das in blender nicht aus
Hier mein Java-Code. Ist schon einige Jährchen alt, daher vermutlich nicht so hilfreich:
Was sein Tutorial angeht: Wenn du es nicht verstehst, schreib dir selber etwas, das du verstehst.
genau das habe ich ja grade versucht 😂
assimp sieht einfacher aus als JSON. Chat GPT hat mir den weg gewiesen! Kann ja falsch sein was er sagt aber funktioniert halt schon so halb, indicis und vector (immhin position) ist richtig. Sind 120 Zeilen insgesammt geworden
Naja, ich würde mich ja eher an OBJ und MTL versuchen. Von Collada rate ich dringend ab.
Was das für ein JSON-Format ist weiß ich nicht, aber da kannst du auch schauen, ob du da eine gute Dokumentation zu findest online. Wie lautet denn die Dateiendung?
Also er hat es für gltf ausgelegt. Auch genau das vormat in dem ich meine blender projekte exportiere.
Ja obj soll einfach sein aber soll auch nicht so viel information haben.
Spezifikation gibt es hier:
https://registry.khronos.org/glTF/
Die scheint recht ausführlich zu sein, da solltest du hoffentlich eine Erklärung für seinen Code finden.
Ich verstehe ja das es blöcke sind die man wie eine hashmap kriegt. Aber ich weiß halt nicht wofür was gut ist. Also ja diffuse ist grundfarbe meine ich, ambient ist licht intensität (ich weiß jetzt schon nicht in welchem block das sein soll) und specular brauch man eine specular map für. Da weiß ich auch nicht in welchem block die sich befinden soll.
Da würde ich leieber einer library nehmen die mir das einfach ausstellt. hat ja aber nicht so gut geklappt... Vermutlich weil ich immernoch nicht weiß wofür was gut ist.
Rückmeldung zu dem code krieg ich ja auch nirgendwo. Auf stack overflow werden meine fragen immer ohne grund gebannt
Schau dir mal folgendes an:
https://de.wikipedia.org/wiki/Phong-Beleuchtungsmodell
Da werden die Antweile "Ambient", "Diffuse" und "Specular" erklärt.
Ja hä genau die weiß ich doch. Aber wo die in der textur sind! Ich denke mal das die diffuse textur die normal textur ist aber hat nicht so toll geklappt in assimp
Ich verstehe nicht, was du wissen möchtest.
In der Regel hast du ein paar Texturen, die du an unterschiedlichen Stellen verwenden kannst.
Ambient-Texture für die Farbe des Materials im ambientem Licht. Diffuse-Texture für die Farbe des Materials im diffusem Licht. Das spekulare Licht ist zumeist weiß, dafür werden andere Parameter, die Roughness oder die Specularity per Textur variiert.
Ja mit den klassen von dem tutorial muss ich nur textures.push_back(Texture("diffuse", texture_path); machen und dann sollte es das sein... Da kann ich ja nicht viel falsch machen!
for (int j = 0; j < aiGetMaterialTextureCount(material, aiTextureType_DIFFUSE); j++) {
print("get diffuse texture at " << j)
aiGetMaterialTexture(material, aiTextureType_DIFFUSE, j, texurePath);
print("got diffuse material")
print(fileDirectory + texurePath->C_Str());
Texture diffuse((fileDirectory + texurePath->C_Str()).c_str(), "diffuse", j);
textures.push_back(diffuse);
print("added one diffuse texture")
texurePath->Clear();
}
C_Str
müsste kleingeschrieben werden, wenn du nicht irgendeine kjomische eigene Klasse für Pfade verwendest, die das, warum auch immer, großschreibt.
Das ist ein aiString und kein normaler ;) hätte ich villeicht noch dazu schreiben müssen
Gibt es vielleicht einbfach ne file wo die mesh class mitgeliefert wird? 😂 also mit VBO, VBA und EBO ? Den rest würde ich vielleicht schaffen 😂
Ne... an den sachen kann es auch nicht liegen
Mir fällt auch grade auf... Müsste eine obj file nicht genau so viele vector pos, texture_uv und normals haben? Weil meine ist ganz komisch!
# Blender 3.4.1
# www.blender.org
mtllib xoneone.mtl
o Würfel.001
v 0.000000 0.000000 2.000000
v 0.000000 8.000000 2.000000
v 0.000000 0.000000 0.000000
v 0.000000 8.000000 0.000000
v 2.000000 0.000000 2.000000
v 2.000000 8.000000 2.000000
v 2.000000 0.000000 0.000000
v 2.000000 8.000000 0.000000
vn -1.0000 -0.0000 -0.0000
vn -0.0000 -0.0000 -1.0000
vn 1.0000 -0.0000 -0.0000
vn -0.0000 -0.0000 1.0000
vn -0.0000 -1.0000 -0.0000
vn -0.0000 1.0000 -0.0000
vt 0.996662 -1.513459
vt 0.002003 -1.508075
vt 0.596113 0.200438
vt 0.996662 2.512113
vt 0.002003 2.506729
vt 0.596113 0.000199
vt 0.007343 -1.513459
vt 0.999332 -1.510767
vt 0.794353 0.200438
vt 0.002003 2.512113
vt 0.999332 2.510767
vt 0.596113 0.200040
vt -0.006008 -1.510767
vt 0.996662 -1.508075
vt 0.596113 0.400279
vt -0.006008 2.510767
vt 0.996662 2.506729
vt 0.794353 0.000199
vt 0.000668 -1.510767
vt 1.006008 -1.510767
vt 0.794353 0.400279
vt 0.000668 2.510767
vt 1.006008 2.510767
vt 0.794353 0.200040
s 0
usemtl Material
f 1/1/1 2/4/1 4/10/1 3/7/1
f 3/8/2 4/11/2 8/22/2 7/19/2
f 7/20/3 8/23/3 6/16/3 5/13/3
f 5/14/4 6/17/4 2/5/4 1/2/4
f 3/9/5 7/21/5 5/15/5 1/3/5
f 8/24/6 4/12/6 2/6/6 6/18/6
Das ist ein aiString und kein normaler ;) hätte ich villeicht noch dazu schreiben müssen
Hätte ich auch selber sehen können. Wie ich sowas hasse, wenn die einfach ihre Methoden unsinnig benennen, statt sich an den existierenden Standard zu halten.
Gibt es vielleicht einbfach ne file wo die mesh class mitgeliefert wird? 😂 also mit VBO, VBA und EBO ? Den rest würde ich vielleicht schaffen
Was meinst du? Willst du einen Assimp-Loader? Oder willst du meine LWJGL-Klasse für die Mesh? Ich könnte dir auch das ganze Projekt geben, aber das ist Vulkan und nur zum testen.
Mir fällt auch grade auf... Müsste eine obj file nicht genau so viele vector pos, texture_uv und normals haben? Weil meine ist ganz komisch!
Greift man nicht dann mittels Index darauf zu? Dann darf man halt nur die Indizes verwenden, für die man Daten angegeben hat.
Und noch einmal zu folgendem:
Ja mit den klassen von dem tutorial muss ich nur textures.push_back(Texture("diffuse", texture_path); machen und dann sollte es das sein... Da kann ich ja nicht viel falsch machen!
Naja, je nachdem. Wenn im TextureStack steht, dass du mit der Textur erst noch etwas machen musst, das machst du hier ja nicht.
Und weiteres hängt auch von der Texture-Klasse ab. Wenn da das Dateiformat nicht passt geht das auch schief.
Also hier der getTextures vom tutorial:
std::vector<Texture> textures;
std::string fileStr = std::string(file);
std::string fileDirectory = fileStr.substr(0, fileStr.find_last_of('/') + 1);
// Go over all images
for (unsigned int i = 0; i < JSON["images"].size(); i++)
{
// uri of current texture
std::string texPath = JSON["images"][i]["uri"];
// Check if the texture has already been loaded
bool skip = false;
for (unsigned int j = 0; j < loadedTexName.size(); j++)
{
if (loadedTexName[j] == texPath)
{
textures.push_back(loadedTex[j]);
skip = true;
break;
}
}
Nur bis hier hion wichtig glaub ich
// If the texture has been loaded, skip this
if (!skip)
{
// Load diffuse texture
if (texPath.find("baseColor") != std::string::npos)
{
Texture diffuse = Texture((fileDirectory + texPath).c_str(), "diffuse", loadedTex.size());
textures.push_back(diffuse);
loadedTex.push_back(diffuse);
loadedTexName.push_back(texPath);
}
// Load specular texture
else if (texPath.find("metallicRoughness") != std::string::npos)
{
Texture specular = Texture((fileDirectory + texPath).c_str(), "specular", loadedTex.size());
textures.push_back(specular);
loadedTex.push_back(specular);
loadedTexName.push_back(texPath);
}
}
}
return textures;
Da nimmt er halt einfach die textur und bearbeitet nichts nach.
Und ich meine die obj file ist komisch weil ich ja in einem vertex die pos, normal, color und tex:uv speicher. Wie soll ich das in einem vertex speichern wenn es von allen unterchiedliche anzahl gibt?
Da nimmt er halt einfach die textur und bearbeitet nichts nach.
Was dann vielleicht auch Ursache für das falsche Erscheinen ist. Darum geht es doch, oder nicht?
Und ich meine die obj file ist komisch weil ich ja in einem vertex die pos, normal, color und tex:uv speicher. Wie soll ich das in einem vertex speichern wenn es von allen unterchiedliche anzahl gibt?
Du verwendest Indices. Wie du siehst bekommt jeder Vertex jeweils einen Index für Position, einen für Norlmale und einen für Textur.
Ohhh er benutzt normal für die indices! Aber woher soll denn der model loader das wissen? Und der code von oben ist von dem tutorial von victor mit dem JSON der hat nicht mit meinem model geklappt aber mit anderen. Und die klappen auch nicht mit assimp.
Und wo kommen die tex_uv's hin? weder in die vertex noch indices passen die
Ohhh er benutzt normal für die indices!
Wo? Was? Hä?
Und wo kommen die tex_uv's hin? weder in die vertex noch indices passen die
Das sind vermutlich Texturkoodinaten. Die hast du pro Vertex. Wie die zugeordnet werden musst du sehen.
Es gibt ja bei dem cube 6 faces und auch 6 normals. Trotzdem komisch das es vn sind... UNd ja tex:uv sind ja textur coordinaten aber ich habe 8 vertices pos und viel viel mehr tex:uvs und weniger normals! Wo soll was hin?!
Ja... und? Erklärt immernoch nicht warum es 8 v und 6 vn gibt! In der website von dir sind auch 4 von allem drinn!
Doch, erklärt es. Du hast acht Ecken und 6 Seiten.
Und diese werden dann für die Definition der 6 Faces verwendet unter Verwendung von Indices.
I aint reading allat! Ne aber im ernst ich kann keine 1000 Zeilen auf Englisch lesen... Und beim überfliegen finde ich nichts. Ich finde nur die deffinition von normals. Und warum heist es dann immernoch vn wenn es nichtmehr die vertex normals sind sondern die face normals? Und Wie soll man das umrechnen? An einem vertex sind 3 faces mit einem vector3 aber ein vertec kann nur 1 vn haben!
Du brauchst dir ja nur die Definitionen der verwendeten Strukturen anschauen bzw. eigentlich auch nur den für Faces.
Die Normals werden hier auch jeweils für die Vertrices je Face angegeben. Du hast je Face vier Vertices mit jeweils eigener Position, Normal und Texture. Die Positionen sind allerdings identisch mit denen von Nachbarfaces.
Guten tag, ich glaube ich habe eine zu alte von glad ausversehen installiert! Und als ich ochmal eine neue runtergeladen habe gibt es nurnoch einen include und einen src ordner! Bei dem alten gab es so viel mehr! Ich habe jetzt mal versucht es wie eine normale header file zu bauen. Aber in glad.c selbst veröangt er nach <glad/glad.h> Also muss es ja irgendwie von cmake besonders bearbeitet werden oder so... Bitte Hilfe
Das ist die neuste version? Weil die jetztige war glaub 3.3
Also für gl 4.6 brauch ich.
Brauch so glCreateVertexArrays(1, uint);
Das ist eine OpenGL-version. Die kommt nicht von GLAD, sondern vom installiertem OpenGL. Installiert wird das via Grafiktreiber iirc (die header bekommt man aber glaube ich auch online).
Du kannst im übrigen auch glGenVerteyArrays verwenden:
https://registry.khronos.org/OpenGL-Refpages/gl4/html/glGenVertexArrays.xhtml
https://stackoverflow.com/questions/24441430/glgen-vs-glcreate-naming-convention
Aber ich habe glfw 3.3.8 und ich meinedie supportet bis zu openGL 4.6. Und die glad_ version exestiert auch nicht...
Ich weiß nicht, welche glad-Version du für OpenGL 4.6 brauchst. Aber eine neuere als die neuste gibt es nicht.
Sprich, entweder schaust du, dass es mit der funktioniert, oder du behälst die alte OpenGL-Version oder du verwendest etwas anderes als glad.
Aber es wäre schon komisch, wenn das glad nicht für die neuste Version ausgelegt ist.
Ja. Aber genau da kriege ich ja nur die include und src folders...
Na aber dass du das angeben kannst heißt doch, dass es unterstützt wird, darum geht es mir.
Also verstehe ich nicht, wo dein Problem liegt.
Also ich lad mir das jetzt von github runter, benenne das glad-glad2 in glad um und behalte die cmake list so wie sie ist?
glCreateVertexArrays auch mit glad_ exestieren immernoch nicht.(glfwExtensionSupported("GL_ARB_direct_state_access"))
ist aber true
Das ist ja auch nichts, was mit glad zusammenhängt. Da fehlt entweder der passende Header oder die Funktion ist nicht implementiert (je nach Fehlermeldung).
Welche Fehlermeldung? Die funktion exestiert einfach nicht
Woher willst du wissen, dass die Funktion nicht existiert, wenn du keinen Fehler erhälst?
Nunja halt
Use of undeclared identifier 'glCreateVertexArray'
Heißt "glCreateVertexArrays". Und der Fehler heißt, dass der Header fehlt, der das deklariert.
Ja... und wo ist der? Mir zeigt esr an das er in dem ist, den ich generiert habe. Der nur mit hder und src foldern ist
Ich weiß nicht, wo das definiert sein sollte. Musst du suchen und danns chauen, warum das nicht in dein Projekt includet wird.
Ich weiß gerade auch nicht, ob wir da irgendwelche Header ausgetauscht hatten.
Vor morgen beschäftige ich mich dmait auch jetzt nicht weiter.
Und da war ja meine frage wie ich das include
Das sollte automatisch includet sein. Wenn deine OpenGL-Version aktuell ist.
Also die function ist jetzt in external/nglad/include/glad.h. Also nicht in openGL selbst bei mir und ich vermute ich kann es nicht einfach so includen wie einen normalen header...
Hier: Obwohl dashier der erste include ist#include "../external/nglad/include/glad/glad.h"
Sagt er mir trotzdem openGL wurde schon defined. Und das in genau der zeile (9)
Das heißt dann, dass du es so nicht includen kannst. Evtl. hast du glad an der falschen Stelle includet oder so, das hatten wir doch schoneinmal, oder nicht?
Ja. Aber jetzt ist es halt an der ersten stelle. So wars mit dem glad vorher auch
Dann musst du schauen, wo das schon einmal definiert wurde, das sollte dir der Compiler eigentlich auch mit ausgeben.
Das ist die einzige header file in die das included ist... Sorry für die später antwort
Du musst nach der definition von "openGL" suchen, die ist irgendwo doppelt.
Ah! Ich hatte noch eine ganz auskommentierte klasse die anscheinend ein paar probleme gefordert hat! Jetzt kriege ich aber -1073741819 (0xC0000005) error... Ich musste auch den parameter aus gladLoadGL nehmen, weil es keine parameter mehr nimmt
Nur bei diesem code:int main() {
glfwInit() ;
glfw::setSTDWindowHints();
Window window = glfw::setNewContext(screenSize.x, screenSize.y, "Hello World!", glfwGetPrimaryMonitor());
glfw::deleteWindow(window);
glfwTerminate();
}
void __glfw_deffi_ setSTDWindowHints() {
setWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 4);
setWindowHint(GLFW_CONTEXT_VERSION_MINOR, 6);
setWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
}
void __glfw_deffi_ setCurrentContext(Window window) {
glfwMakeContextCurrent(window);
gladLoadGL();
int width, height;
glfwGetWindowSize(window, &width, &height);
glViewport(0, 0, width, height);
}
Ja... der code den ich oben geschrieben habe klappt nicht. Dieser simple code:
int main() {
glfwInit() ;
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 4);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 6);
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
Window window = glfwCreateWindow(800, 800, "Hallo", 0, 0);
glfwMakeContextCurrent(window);
gladLoadGL();
glfw::deleteWindow(window);
glfwTerminate();
}
Fehler: -1073741819 (0xC0000005) includes
#include "../external/nglad/include/glad/glad.h"
#include <functional>
#include <GLFW/glfw3.h>
#include "list.h"
#include <glm/glm.hpp>
#include <glm/gtc/type_ptr.hpp>
#include <thread>
#include <chrono>
#include <cstdint>
Ich weiß nicht, was der fehler bedeutet. certutil sagt:
Text der Fehlermeldung: Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx.
Der Vorgang %s konnte nicht im Speicher durchgeführt werden.
Das muss aber nichts heißen.
Schau erst einmal, welches Command das problem verursacht: Dann schau, ob du, wie auf StackOverflow geraten, irgendeinen Context erst laden musst oder soetwas.
Ich kenne mich mit GLAD nicht aus, da kann ich dir nicht wirklich helfen.
Ich habe jetzt die methode gladLoadGLLoader((GLADloadproc)glfwGetProcAddress);
Wie in learnopengl.com verwendet. Die funktion ist undefined
FAILED: GLTest.exe
cmd.exe /C "cd . && C:\msys64\ucrt64\bin\c++.exe -g CMakeFiles/GLTest.dir/main.cpp.obj CMakeFiles/GLTest.dir/sources/types.cpp.obj CMakeFiles/GLTest.dir/sources/stb_image.cpp.obj CMakeFiles/GLTest.dir/sources/glfwUtils.cpp.obj CMakeFiles/GLTest.dir/sources/console.cpp.obj CMakeFiles/GLTest.dir/sources/shader.cpp.obj CMakeFiles/GLTest.dir/sources/file.cpp.obj CMakeFiles/GLTest.dir/sources/gameUtils.cpp.obj -o GLTest.exe -Wl,--out-implib,libGLTest.dll.a -Wl,--major-image-version,0,--minor-image-version,0 libglad_gl_core_33.lib external/glfw-3.3.8/src/libglfw3.lib -lopengl32 -lglu32 -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ."
C:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/GLTest.dir/main.cpp.obj: in function `main':
C:/Users/alpha/Desktop/GLTest/main.cpp:178: undefined reference to `gladLoadGLLoader'
collect2.exe: error: ld returned 1 exit status
Na wenn es die nicht gubt, dann gibt es sie nicht. Dann fehlt entweder der entsprechende header oder du musst etwas anderes tun. Wie gesagt, ich kenne mich nicht aus und habe gerade anderes zu tun. Musst du etwas rumprobieren, googeln und Documentation lesen.
Ah! Ich musste noch die glad.c zu meiner CMakeLists hinzufügen... Und dann musste ich noch in glad.c den include von der glad.h den pfand ändern.
Danke für deine hilfe jetzt geht wieder alles!
Egal was ich mache ich schaff es einfach nicht selber eine library einzubinden 😂! Ich würde gerne assimp verwenden weil mir das alles mit den accessorn und bufferViews zu kompliziert ist... Da es immer ein paar minuten dauert das projekt dann zu bauen, wenn ich sie normal einbinde habe ich versucht die lib zu installieren. Aber er gibt mir immer undeined errors zu den assimp funktionen die ich verwende! Vielleicht habe ich auch schon mein vcpkg kaputt gemacht und darum funktionieren die neusten versuche nicht 😂. Aber ich habe den ordner gelöscht und es neu von git geclont wie es in der anleitung von assimp steht: https://github.com/assimp/assimp/blob/master/Build.md . Ich habe aucvh das in der cmake list hinzugefügt was am ende von der installation m cmd steht: find_package(assimp CONFIG REQUIRED)
target_link_libraries(main PRIVATE assimp::assimp)
Und ich habe bei den CMake options auch das hinzugefügt was im cmd stand:
"-DCMAKE_TOOLCHAIN_FILE=C:/Users/alpha/vcpkg/scripts/buildsystems/vcpkg.cmake"
Also ich verstehe echt das problem bei mir nicht...
Ich versuche es schonwieder seit 5 tagen einen modelimporter ranzukriegen
Ist doch dasslebe wie sonst auch. Musst du halt schauen, wo es hakt. Findet er Assimp gar nicht? (Was setzt denn der Find-File für Assimp) oder machst du sonst etwas falsch.
Er muss ja einen File FindAssimp.cmake oder so (gibt auch files für cmake die anders heißen) haben, sonst würde CMake meckern. Finde den und schau, was der tut und dann debug den mit message-Aufrufen um herauszufinden, was du falsch machst.
Vermutlich musst du nur eine Variable im PATH passend setzen.
Hm... ich verstehe das ganze zeug immernoch nicht weil ich mich damit eigendlich nicht beschäftige. Also ja, es gibt eine file mit diesem namen in:
C:\Users\alpha\vcpkg\buildtrees\assimp\src\v5.2.5-5480fca19f.clean\cmake-modules
jetzt habe ich in dem else(WIN32) block vor dem hier:
if (assimp_INCLUDE_DIRS AND assimp_LIBRARIES)
SET(assimp_FOUND TRUE)
Dann das geschrieben:
message("Includes includedirs")
message(assimp_INCLUDE_DIRS)
meesage(assimp_LIBRARIES)
aber es kommt kein output weil ich wahrscheinlich die locale cmakelists.txt console offen habe aber da nicht der output von der cmake list gezeigt wird oder?
Naja, Lass dir doch mal ein "TEST" irgendwo unbedingt ausgeben, am besten da und einmal ind einer CMakeList. Und auch einmal "assim_FOUND" in deiner CMakeList. Dann siehst du ja, ob die Aushgabe geht und ob assimp gefunden wurde.
Mir fiel grade auf das die message statments die ich in Findassimp geschrieben ahbe falsch war aber es hat keinen error gegeben! Trotzdem hab ich das jetzt mal correct in meine geschrieben:
message(WARNING "Includes includedirs")
if(assimp_INCLUDE_DIRS)
message(WARNING "includesdirs")
endif(assimp_INCLUDE_DIRS)
if(assimp_LIBRARIES)
message(WARNING "includeslibs")
endif(assimp_LIBRARIES)
Aber der outoput sit nur:
CMake Warning at CMakeLists.txt:74 (message):
Includes includedirs
Also wurde assimp wohl nicht gefunden richtig?
Und jetzt? Keine Ahnung 😂
Vermutlich. Dann schau mal, wo die Variablen definiert sein müssten. So, wie die klingen sind das keine Umgebungsvariablen, sondern da irst irgendein anderer File, der evtl. includet wird oder in der näheren Umgebung leigt, der die Variablen definieren sollte.
Beispielsweise
assimp-config.cmake
- Warum hab wieder nur ich das problem? 2. Der path ist komisch: C:\Users\alpha\vcpkg\buildtrees\assimp\src\v5.2.5-5480fca19f.clean\cmake-modules
3.Es gibt 12 cmake files. Soll ich alle durchschauen und wenn ja nach was genau oder bin ich komplett im falschen dir
1.) Weil du dich nicht auskennst und deshalb Zeug kompliziert machst. Was aber auch daran liegt das Zeug kompliziert ist teilweise, nicht nur du hast das Problem.
2.) Wei du vcpkg nutzt? Keinen Plan, was das tut, aber offenbar tut es nicht das, was es soll.
3.) Du sollst halt nach Dingen mit assimp suchen und schauen, wo die Libs gesucht werden und so.
Du kannst evtl. auch schauen, wo die tatsächlich leigen und ob eine Environment variable gesetzt wurde oder soetwas.
ist irgendwas für python oder so denke ich mal...
Und ich weiß nicht wie etwas aussieht, das nach irgendwelchen libs sucht. :(
assimp.lib oder assimp.dll
Unjd die Include-Files. Müssen irgendwo in einem Ordner liegen und du musst irgendwie den Ordner passend in deinen CMakeFile bekommen, wahrscheinlich indem du eine Environment-Variable passend setzt oder den ort wo die Dateien liegen zu deinem Pfad hinzufügst oder so.
Warum baust du dir Assimp eigentlich nicht auch selber? Das wäre doch eigentlich am einfachsten, dann sparst du dir das Package-Chaos.
So, wie du die anderen Libs halt auch eingefügt hast.
Mit add_subdirectory habe ich ja schon gemeint, das es dann mehrere minuten baut! Immer wenn ich das projekt baue. Außerdem bin ich grade nicht zuhause also sorry für die späte antwort
Dann bau die Library als Sharded, dann geht es evtl. schneller.
(Denn die Library selbst sollte er ja nur einmal bauen, außer dei Files werden gelöscht oder soetwas.)
Habe ich glaub ich früher auch schonmal versucht aber war vermutlich falsch weil es das gleiche gemacht hat.
Du müsstest schauen, was genau es da baut. Und dann schauen, warum es das erneut baut, obwohl es das doch schon gebaut hat.
Jedes Mal? Klingt für mich komisch. Schau mal, was mit den gebauten Files passiert, ob die irgendwie verschwinden oder so. Vielleicht macht CLion da auch Mist.
Viele klausuren grade... Aber jetzt ist es vorbei! Also... Grade habe ich es denke ich wieder als static library eingebunden da ich damals mal assimo mir angeschaut ahbe aber es dann einfach gelassen habe. Jetzt krieg ich das includen nichtmal mehr hin xD! Einfach nur
add_subdirectory(external/assimp) geht nichtmehr hm... Auch wenn ich die target_link_library umänder zu: target_link_libraries(${PROJECT_NAME} PRIVATE glad_gl_core_33 ${GLFW3_LIBRARY} glfw ${OPENGL_LIBRARIES} assimp) geht es nicht
Ah! Hab immernoch das für die installation im ordner gehabt oder so. Habs neu geclont und jetzt baut es. Dauert halt noch... Diese meldungen und so:
[23/406] Building CXX object external/assimp/code/CMakeFiles/assimp.dir/AssetLib/3DS/3DSConverter.cpp.obj
[24/406] Building CXX object external/assimp/code/CMakeFiles/assimp.dir/AssetLib/AMF/AMFImporter_Geometry.cpp.obj
Ja, das sollte an sich, wenn es einmal gebaut ist, halt nicht noch einmal alles bauen, außer die Zwischendateien werden irgendwie gelöscht oder so. Das müsstest du dann untersuchen.
Mal sehen. Es baut noch. Aber wird es denn dann trotzdem jedes mal neu gebaut wenn ich die cmake-build-debug dir lösche?
Wenn da die Zwischendateien drinnenliegen dann ja. Oder vielleicht auch in anderen Fällen wenn cmake Zeug falsch macht oder das Zeug falsch konfiguriert ist.
Gutefrage geht grade auf chrome nicht... musste in den tor browser. Hier die nachricht die ich senden wollte:
Ahhh okay. Weil ich muss den immer löschen damit mein assets ordner mit kopiert wird und ich die assets benutzen kann! Wie soll ich das anders machen? Grad hab ich es so:
file(COPY ${ASSETS_SOURCE_DIR} DESTINATION ${CMAKE_CURRENT_BINARY_DIR})
Wenn ich das nicht mache kann ich den ordner nicht mit relativem path benutzen.
Probier mal soetwas wie:
install(DIRECTORY
${CMAKE_CURRENT_LIST_DIR}/scenes DESTINATION ${CMAKE_INSTALL_BINDIR}
)
(Ist jetzt aus einem anderem Project. Das kopiert den Subordner "scenes" in das Binary-Directory am Install-Ort.)
Das wird zumindest bei mir immer aufgerufen wenn ich einen entsprechenden File verändere.
Vielleicht muss ich pfade setzten? Habe meine code jetzt einfach durch: install(DIRECTORY
${CMAKE_CURRENT_LIST_DIR}/assets DESTINATION ${CMAKE_INSTALL_BINDIR}
)
ersetzt.
Kriegen aber "Texture is null" Das wird ausgegeben wenn:
localBuffer = stbi_load(pathName.c_str(), &width, &height, &bitsPerPixel, 4);
if (!localBuffer)
printErr("Texture is null");
Und sie assets folder gibt es auch nicht im cmake-build-debug
Klar musst du Pfade ersetzen. Du packst das Zeug ja jetzt in einen anderen Ordner.
Wohlgemerkt musst du das Projekt auch installieren. Also
cmake install
oder so.
keine ahnung... 😂 Ein projekt installieren? Wie mache ich das und zu was muss ich die paths setzen? Maan alles so kompliziert
Lies dich dazu am besten im Internet schlau. Das macht deine IDE vielleicht sogar schon. Da kannst du mal schauen, ob du einen install-Ordner oder so findest.
Wenn du im Internet nichts findest kann ich dir morgen einen befehl schicken, wie man das macht.
Finde nichts wenn ich "how to install my c++ project" suche... Nur wie man es builded oder c++ an sich installiert. CLion erstellt nur eine "cmake-build-debug". Da ist auch nichts was irgendwie install heißt drinne.
Such nach cmake und install. Und evtl. noch nach deiner IDE dazu.
https://www.jetbrains.com/help/clion/using-cmake-install.html
Ist das jetzt alles nur damit der assets ordner funktioniert? xD Ich versteh wenn es darum geht irgendwie immer nur Bahnhof. Ich habe das so verstanden das CMake, nunja und make alles Build-systeme sind aber CLion alle gleichzetig benutzt?!
Naja hab es jetzt: function(copy_assets)
file(COPY ${ASSETS_SOURCE_DIR} DESTINATION ${CMAKE_CURRENT_BINARY_DIR})
endfunction()
copyassets()
und es klappt bei dem test
Das installieren packt alle wichtigen Dateien in einen neuen Ordner. Also beispielsweise die fertige Executable, die fertigen Libraries, Assets, ...
Ich habe das so verstanden das CMake, nunja und make alles Build-systeme sind aber CLion alle gleichzetig benutzt?!
CLion sollte nur eines davon verwenden, sonst gibt es nur unnötig Chaos.
und es klappt bei dem test
Na hoffentlich bleibt das auch so, das ist wirklich ser hacky. Ich meine, das sollte ja eigentlich gleich funktionieren, egal ob jetzt in einer Funktion oder nicht.
Hallo irgendwie klappt das bei mir nicht...
Ich habe halt garkeine ahnung davon.
Ich habe jetzt das in cmake probiert aus dem ersten link
Hat nicht geklappt. dann habe ich noch aus dem zweitem link add_subdirectory()
und da C:\Users\alpha\OneDrive\Dokumente\GLFW eingefügt was der ordner mit dem glfw-3.3-8-bin.WIN64 drin ist. Hat alles nicht funktioniert
Also bei dem add_subdir sagt er mir direct wenn ich \ eingeben einen Fehler