Chciałbym bawić się biblioteką Allegro, ale nie mogę sprawić, że mój projekt testowy poprawnie się połączy. Dokładnie, otrzymuję błędy cannot find -l<...>
, gdzie <...>
jest plikiem, który określiłem przy użyciu target_link_libraries
. (Szczegółowe informacje znajdują się poniżej).CMake nie może znaleźć statycznej biblioteki przy użyciu względnych ścieżek plików
Dla porównania, nie znam się dobrze na procesie tworzenia, a moje zwykłe podejście to "kliknij przycisk i mam nadzieję, że pojawi się plik wykonywalny, jeśli nie, skorzystaj z próba i błąd. " Znalazłem sporo podobnych pytań tutaj, ale wydaje się, że albo problemy, albo rozwiązania różnią się od tego, czego doświadczam. Mam nadzieję na wyraźne "oto, co robisz źle, a oto co robić zamiast tego".
Powiedział, że to jest mój struktury projektu:
/include
/lib
/src
main.cpp
CMakeLists.txt
include i lib ja skopiowane z Allegro binary package i lib gdzie wszystkie .a pliki znajdują.
Oto co mówi mój CMakeLists.txt:
cmake_minimum_required(VERSION 3.2)
project(AllegroTest)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -static-libgcc -static-libstdc++ -fpermissive")
add_definitions(-DALLEGRO_STATICLINK)
file(GLOB SOURCES src/*.cpp)
set(SOURCE_FILES ${SOURCES})
add_executable(AllegroTest ${SOURCE_FILES})
include_directories(include)
target_link_libraries(AllegroTest
liballegro-5.0.10-static-mt.a
liballegro_acodec-5.0.10-static-mt.a
liballegro_audio-5.0.10-static-mt.a
libvorbisfile-1.3.2-static-mt.a
libvorbis-1.3.2-static-mt.a
liballegro_color-5.0.10-static-mt.a
liballegro_dialog-5.0.10-static-mt.a
liballegro_font-5.0.10-static-mt.a
liballegro_image-5.0.10-static-mt.a
liballegro_memfile-5.0.10-static-mt.a
liballegro_physfs-5.0.10-static-mt.a
liballegro_primitives-5.0.10-static-mt.a
liballegro_ttf-5.0.10-static-mt.a
libdumb-0.9.3-static-mt.a
libFLAC-1.2.1-static-mt.a
libfreetype-2.4.8-static-mt.a
libogg-1.2.1-static-mt.a
libzlib-1.2.5-static-mt.a
libopenal-1.14-static-mt.a
)
target_link_libraries(AllegroTest
libgdiplus.a
libuuid.a
libkernel32.a
libwinmm.a
libpsapi.a
libopengl32.a
libglu32.a
libuser32.a
libcomdlg32.a
libgdi32.a
libshell32.a
libole32.a
libadvapi32.a
libws2_32.a
libshlwapi.a
)
A oto błędy Dostaję:
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: cannot find -lallegro-5.0.10-static-mt
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: cannot find -lallegro_acodec-5.0.10-static-mt
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: cannot find -lallegro_audio-5.0.10-static-mt
<etc.>
Próbowałem określając ścieżkę w każdy możliwy sposób — tym połączeniu to z użyciem link_directories(lib)
—, ale nic nie wydaje się mieć żadnego wpływu.
Jedyną czynnością, jaką wykonał jest podanie bezwzględnej ścieżki (C:/Users/<...>/lib/liballegro-5.0.10-static-mt.a
), ale wydaje mi się, że jest to dalekie od idealnego sposobu.
Jaki błąd popełniam tutaj i jaki jest zalecany sposób jego naprawy?
Czuję, że przy absolutnych ścieżkach projekt nie będzie już samowystarczalny i zamiast tego polegać będzie na jego otoczeniu. Przypuszczam, że "CMAKE_CURRENT_SOURCE_DIR" to sposób obejścia tego, więc dziękuję za wzmiankę o tym. Czy naprawdę nie ma sposobu pracy z prawdziwie względnymi ścieżkami? Wydaje mi się, że powinno być. – vvye
Spodziewałbym się, że "link_directories (lib)" naprawi to jako szczere, ale odradza się używanie 'link_directories' - nawet w jego [własnej dokumentacji] (http://www.cmake.org/cmake/help /v3.2/command/link_directories.html). Bardzo często można znaleźć wystąpienia "CMAKE_SOURCE_DIR" i "CMAKE_CURRENT_SOURCE_DIR" - uważam, że jest to dobra praktyka. Zapobiega to konieczności sprawdzania dokumentów dla poleceń, w których nie masz pewności, czy traktują ścieżki jako względne względem katalogu głównego źródła lub katalogu głównego. – Fraser
Przynajmniej teraz rozumiem twoją niechęć, jeśli myślałeś, że będziesz musiał przepisać bezwzględne ścieżki z własnej maszyny - za każdym razem trzeba tego unikać :) – Fraser