Problem z CMake, conanem i VisualStudio 2022

Cześć wszystkim.
mam poważny problem z instalacją zewnętrznych pakietów pod VisualStudio 2022 przy użyciu Conana. Problem polega na tym, że pakiety dla Visual Studio są niewidoczne. find_package krzyczy, że nie może znaleźć pliku configowego cmake dla pakietu. Na przykład dla fmt fmtConfig.cmake lub fmt-config.cmake. Takie pliki powstają w katalogu conana i teoretycznie wszystko powinno działać. Próbowałem też z microsoftowym menedżerem pakietów i sytuacja jest taka sama.
Z góry dziękuję za odzew!

A jakieś szczegóły techniczne?
Nie odziedziczyłem magicznej kryształowej kuli, by się domyśleć w czym problem.

Co prawda to nie rozwiązanie Twojego problemu, ale może

include(FetchContent)

FetchContent_Declare(fmt
  URL https://github.com/fmtlib/fmt/releases/download/8.1.1/fmt-8.1.1.zip
)
FetchContent_MakeAvailable(fmt)

@Bartłomiej Golenko: Dzięki, ale takich bibliotek będzie sporo i... To nie jest zbyt dobre rozwiązanie.
@MarekR22:
Problem występuje na 2 systemach operacyjnych, Windows 11 i Windows 10. IDE Visual Studio 2022 Community Edition

Plik projektowy CMakeLists.txt wygląda mniej więcej tak (umieściłem mniej zależności i zmieniłem nazwę):

cmake_minimum_required (VERSION 3.8)

project ("Projekt")
set(CMAKE_CXX_STANDARD 17)
find_package(fmt REQUIRED)
find_package(gtest REQUIRED)
find_package(rabbitmq-c REQUIRED)
add_subdirectory ("ProjektSrc")
target_link_libraries("Projekt" fmt::fmt)


include("build/conanbuildinfo.cmake")
conan_basic_setup()
add_subdirectory ("tests")

Oto kroki które wykonuję:

mkdir build
cd build
cmake .. -G "Visual Studio 17 2022" -DCMAKE_TOOLCHAIN_FILE=./build/conan_toolchain.cmake

I taki komunikat błędu:

  Could not find a package configuration file provided by "fmt" with any of
  the following names:

    fmtConfig.cmake
    fmt-config.cmake

  Add the installation prefix of "fmt" to CMAKE_PREFIX_PATH or set "fmt_DIR"
  to a directory containing one of the above files.  If "fmt" provides a
  separate development package or SDK, be sure it has been installed.

A w cmake kolejność nie ma przypadkiem znaczenia ?

jak ogladam przykład conan-a to jest

include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)
conan_basic_setup()

add_executable(md5 md5.cpp)
target_link_libraries(md5 ${CONAN_LIBS})

conanbuildinfo.cmake ustawia środowisko miedzy innymi "CMAKE_PREFIX_PATH"

W czym conan jest lepszy od czystego CMAKE+znajomość narzędzia ?
Robiłem dwa podejścia do conan i strasznie utrudnia życie

Adamek Adam napisał(a):

W czym conan jest lepszy od czystego CMAKE+znajomość narzędzia ?

Conan to jest package manager, którego można zintegrować z cmake.
Zależności są automatycznie ściągane i w razie potrzeby budowane.
Ręczne dłubanie z cmake nie jest przyjemne.

meehow.cpp napisał(a):

Kopiuj

  Could not find a package configuration file provided by "fmt" with any of
  the following names:

    fmtConfig.cmake
    fmt-config.cmake

  Add the installation prefix of "fmt" to CMAKE_PREFIX_PATH or set "fmt_DIR"
  to a directory containing one of the above files.  If "fmt" provides a
  separate development package or SDK, be sure it has been installed.

Nie ma tam, żadnych logów z Conan? Nie ściągnął fmt?

Conan nadpisuje katalog w którym wyszukiwane są pliki cmake, więc jeśli biblioteka jest zainstalowana w systemie, a Conan jest w użyciu, to wtedy ta instalacja zostania zostanie ukryta.

Ręczne dłubanie z cmake nie jest przyjemne. ...
Gdzieś już to słyszałem ...
Aha pamiętam, pewna "Website designer" mówiła to samo o Pajączku, bo ręczne dłubanie w html nie jest przyjemne.

Nie ma tam, żadnych logów z Conan? Nie ściągnął fmt?

Conan nadpisuje katalog w którym wyszukiwane są pliki cmake, więc jeśli biblioteka jest zainstalowana w systemie, a Conan jest w użyciu, to wtedy ta instalacja zostania zostanie ukryta.

  Microsoft (R) C/C++ wersja kompilatora optymalizujÄ…cego 19.32.31329 dla x64

  CheckIncludeFile.c

  Copyright (C) Microsoft Corporation. Wszystkie prawa zastrzeĹĽone.

  cl /c /Zi /W3 /WX- /diagnostics:column /Od /Ob0 /D _MBCS /D WIN32 /D _WINDOWS /D "CMAKE_INTDIR=\"Debug\"" /Gm- /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /Fo"cmTC_133fd.dir\Debug\\" /Fd"cmTC_133fd.dir\Debug\vc143.pdb" /external:W3 /Gd /TC /errorReport:queue D:\Repositories\projekt\build\CMakeFiles\CMakeTmp\CheckIncludeFile.c

D:\Repositories\projekt\build\CMakeFiles\CMakeTmp\CheckIncludeFile.c(1,10): fatal error C1083: Nie można otworzyć pliku dołącz: 'pthread.h': No such file or directory [D:\Repositories\projekt\build\CMakeFiles\CMakeTmp\cmTC_133fd.vcxproj]

Wszystkie zależności są i te pliki Config.cmake też są, tylko cmake nie może ich złapać.
Prześledziłem rozwiązania z tym pthread i wrzuciłem w CMakeLists.txt:

set(CMAKE_CXX_STANDARD 17)
option(CMAKE_USE_WIN32_THREADS_INIT "using WIN32 threads" ON)
	set(THREADS_USE_PTHREADS_WIN32 true)
	include("build/conanbuildinfo.cmake")
find_package(Threads REQUIRED)
include_directories(${THREADS_PTHREADS_INCLUDE_DIR})
	conan_basic_setup()

Nic to nie dało

Adamek Adam napisał(a):

W czym conan jest lepszy od czystego CMAKE+znajomość narzędzia ?
Robiłem dwa podejścia do conan i strasznie utrudnia życie

Problem jest globalny i nie dotyczy jedynie Conana. Microsoftowego menadżera też. Nawet jak podincluduje mu fmtConfig.cmake, pokasuję wszystkie katalogi cmake i buildów i buduję od nowa to on dalej pluje się o ten plik.

btw. to nie jest Linux w którym masz repozytorium z biliotekami i poinstalujesz sobie w 5 minut zależności. Gdybym miał zaciągać wszystkie liby ręcznie i dorzucać im cmake, to pewnie hello world napisałbym pod koniec 2046 roku. Tu będzie dużo zależności.

Opcja 1) Poszukać w CMAKE opcji aby wyświetlał wszystkie wykonywane polecenia

u mnie działa coś takiego:
po project(...)
dodaje
set(CMAKE_VERBOSE_MAKEFILE ON CACHE BOOL "ON" FORCE)

nie powinno być kilka folderów gdzie są pliki nagłówkowe ? Na przykładzie conan mam kilkanascie folderow do bibliotek zależności

Opcja 2) zainteresować się https://www.msys2.org/

Opcja 3) Poprawić CMakeLists.txt conanfile.txt

cmake_minimum_required (VERSION 3.8)

project ("Projekt")
set(CMAKE_CXX_STANDARD 17)


include("build/conanbuildinfo.cmake")
conan_basic_setup()
add_subdirectory ("ProjektSrc")
target_link_libraries("Projekt" ${CONAN_LIBS}) 
add_subdirectory ("tests")

[requires]
...
fmt/8.1.1
gtest /....

u mnie działa ten przykład https://docs.conan.io/en/latest/getting_started.html
dodałem kilka bibliotek conanfile.txt a potem uzylem w pliku md5.cpp

u mnie działa ten przykład https://docs.conan.io/en/latest/getting_started.html
dodałem kilka bibliotek conanfile.txt a potem uzylem w pliku md5.cpp

U mnie też on działa. Działa wszystko co nie wymaga generatorów:
MSBuildDeps
MSBuildToolchain
Tu jest coś pochrzanione.

Na GCC nie będę miał drivera do MSSQL Server, a potrzebuję. :/

Zaorałem całe środowisko, postawiłem na nowo i... jeszcze inny błąd... To jest jakaś masakra. To ewidentnie problem po stronie cmake.

Oranie dobrze działa na glebę a nie na problemy programistyczne ;)
od niedawna walcze z c++ ale zanim zaczełem to obejrzałem kilka IDE , koniec końców do scalenia projektu uzywam CMAKE a jako edytor Visual Studio Code (albo cokolwiek co mam pod ręką np. notepad++ , mcedit itp...)

Moje wymagana co do środowiska pracy:

• wielo platformowy (win,lin, cross->arch64)
• brak ostawień poza folderem projektu
• wszystkie zależności są budowane w cmake
• skompiluje projekt za 15 lat

Wybranie jednego konkretnego IDE jest jak ślub , jak będziesz chciał się rozstać to trochę będzie Cie kosztowało

Adamek Adam napisał(a):

Oranie dobrze działa na glebę a nie na problemy programistyczne ;)
od niedawna walcze z c++ ale zanim zaczełem to obejrzałem kilka IDE , koniec końców do scalenia projektu uzywam CMAKE a jako edytor Visual Studio Code (albo cokolwiek co mam pod ręką np. notepad++ , mcedit itp...)

Moje wymagana co do środowiska pracy:

• wielo platformowy (win,lin, cross->arch64)
• brak ostawień poza folderem projektu
• wszystkie zależności są budowane w cmake
• skompiluje projekt za 15 lat

Wybranie jednego konkretnego IDE jest jak ślub , jak będziesz chciał się rozstać to trochę będzie Cie kosztowało

To nie ja wybrałem IDE. Mam takie wytyczne. Ja w ogóle używam CLiona w moich projektach i piszę głównie pod Linuksa, ale teraz mam projekt pod Visual C++ do zrobienia i nie przeskoczę tego. Nie mogę narzucać zlecającemu technologii. Nie tylko visual mi tu nie pasuje. Tu jest więcej problematycznych obszarów które dużym nakładem pracy pokonałem - jak archaiczne biblioteki które trzeba było obudować w XXI wiek.
Co postawienie środowiska to inny zestaw błędów. To co jest absurdalne, cmake nie czyści przy deinstalacji wszystkich swoich plików. Pozostają ślady. Ja część katalogów pokasowałem, ale coś mogło zostać. Nawet w program files zostają pozostałości - co jest niedopuszczalne. Program przy deinstalacji powinien po sobie porządnie posprzątać.

Co dokładnie jest narzucone ?
Tylko IDE, czy tylko kompilator , czy jeszcze jakieś narzędzia ?

A CLion moze uzyc kompilatora MS przez cmake ?

Bo moze tak ?

1. uzywasz CMAKE do generowania projektów
2. Ty uzywasz dowolnego IDE jakie lubisz
3. Inne osoby uzywają to co lubią/muszą np. VS
   I wszyscy sa zadowoleni

co znaczy "cmake nie czyści" ? Chodzi o budowę projektu czy instalację samego cmake.

Adamek Adam napisał(a):

Co dokładnie jest narzucone ?
Tylko IDE, czy tylko kompilator , czy jeszcze jakieś narzędzia ?

A CLion moze uzyc kompilatora MS przez cmake ?

Bo moze tak ?

1. uzywasz CMAKE do generowania projektów
2. Ty uzywasz dowolnego IDE jakie lubisz
3. Inne osoby uzywają to co lubią/muszą np. VS
   I wszyscy sa zadowoleni

co znaczy "cmake nie czyści" ? Chodzi o budowę projektu czy instalację samego cmake.

Potrzebuję środowisko pod VisualC++ z możliwością dociągania pakietów. Problem jest nie po stronie conana, a po stronie cmake. Wczoraj próbowałem z VCPKG i też nie trybiło. CMake po deinstalacji pozostawia mnóstwo śmieci poza projektem w różnych katalogach.

VisualC++ to dla mnie kompilator wiec IDE może być dowolne ;)

Musiał byś umiesci na GIT-a jakis prosty przykład tego co robisz i jak bo ja nie wiem z czym masz problem (a moze sie czegos naucze)

z cmake mam zwiazane dwa foldery
tam gdzie jest binarka cmake
c:\bin\cmake<XYZ wersja>\bin
oraz "build" w folderze projektu i w tym folderze cmake zapisuje swoje smieci
jak kasuje "build" to nie ma żadnych śmieci

jak uzyłem conana to rzeczywiście zrobił sie smietnik bo on trzyma swoje pliki "gdzieś"

Napisz co dla Ciebie znaczy PAKIET , to jakiś format MS czy po prostu repozytorium GIT-a na github

Adamek Adam napisał(a):

VisualC++ to dla mnie kompilator wiec IDE może być dowolne ;)

Musiał byś umiesci na GIT-a jakis prosty przykład tego co robisz i jak bo ja nie wiem z czym masz problem (a moze sie czegos naucze)

z cmake mam zwiazane dwa foldery
tam gdzie jest binarka cmake
c:\bin\cmake<XYZ wersja>\bin
oraz "build" w folderze projektu i w tym folderze cmake zapisuje swoje smieci
jak kasuje "build" to nie ma żadnych śmieci

jak uzyłem conana to rzeczywiście zrobił sie smietnik bo on trzyma swoje pliki "gdzieś"

Napisz co dla Ciebie znaczy PAKIET , to jakiś format MS czy po prostu repozytorium GIT-a na github

Ale ja nie piszę nic o IDE. Z konsoli to nie działa. Tworzysz czysto CMakowy projekt, podrzucasz mu cmakeconfig pod nos, w include i on też nie widzi, gubi się. Pod conanem nie widzi, pod VCPKG nie widzi. Jak nie potrzebujesz microsoftowego toolchaina, wszystko śmiga, ale niektóre pakiety go wymagają: MSBuildDeps
MSBuildToolchain - przy tym cmake nie działa. Jak uda mi się wywalczyć żeby wygenerował się plik toolchaina to wywala, że nie widzi pliku pthread do tempowego pliku generowanego przez cmake. Błąd jest po stronie cmake.

D:\Repositories\hidaeroserver\build\CMakeFiles\CMakeTmp\CheckIncludeFile.cxx(1,10): fatal error C1083: Nie można otworzyć pliku dołącz: 'pthread.h': No such file or directory [D:\Repositories\hidaeroserver\build\CMakeFiles\CMakeTmp\cmTC_c8bfa.vcxproj]

Nie dodajesz nowych danych , spróbuj opisać problem inaczej , opisać co robisz , podeprzeć to przykładem
Bład tylko informuje że projekt który budujesz nie potrafi znaleźć pliku pthread.h , a przyczyn tego moze byc multum

I najwazniejsze , czy masz w ogóle taki plik pthread.h ?

Adamek Adam napisał(a):

Nie dodajesz nowych danych , spróbuj opisać problem inaczej , opisać co robisz , podeprzeć to przykładem
Bład tylko informuje że projekt który budujesz nie potrafi znaleźć pliku pthread.h , a przyczyn tego moze byc multum

Napisałem już. Nie mam możliwości instalacji bibliotek w cywilizowany i profesjonalny sposób, tj poprzez jakikolwiek menadżer pakietów w projektach cmake. Problem dotyczy nie tylko conana. Pisałem już o tym.
W przypadku MSVC++ cmake nie powinien generować pliku zawierającego includa z pthread bo to uniksowa biblioteka.
W systemach windows masz tak jakby warstwy - reprezentacje - są unixowa i windowsowa - windowsowa to windows i windows on windows dla 32 bit - tylko w unixowej będzie działać pthread - czyli pod clang i gcc, pod msvc++ leci tylko warstwa windows która zawiera potrzebne mi do projektu składniki, których nie uświadczę w unixowej warstwie.
cmake nie powinien generować niczego pod toolchain microsoftowy co zawiera pthread - to błąd.

cmake nie generuje nic o co go nie poprosisz
CheckIncludeFile.cxx powstaje aby zweryfikowac plik H , nie jest on w zadne sposób dołaczany do Twojego projektu (tymczasowy plik)

Ja bym sie zastanowił dlaczego Twoj cmake weryfikuje istnienie pthread.h
Może sam to włączyłeś tylko nie jesteś świadomy bo jest to zakopane bardzo bardzo głeboko

Adamek Adam napisał(a):

cmake nie generuje nic o co go nie poprosisz
CheckIncludeFile.cxx powstaje aby zweryfikowac plik H , nie jest on w zadne sposób dołaczany do Twojego projektu (tymczasowy plik)

Ja bym sie zastanowił dlaczego Twoj cmake weryfikuje istnienie pthread.h
Może sam to włączyłeś tylko nie jesteś świadomy bo jest to zakopane bardzo bardzo głeboko

Sorry, ale ten błąd pojawia się nawet w pustym projekcie. Pisałem o tym i co go powoduje. Nie chce mi się tego szukać i wpisywać trzeci raz. To znany błąd. Jedyne rozwiązanie jakie znalazłem to cmake 3.6, ale ono nie działa z VS powyżej 2015. Ja mam kod w C++17 więc...

btw. błąd się pojawia podczas budowania zależności - moje działanie, konfigurowanie czegokolwiek nie ma tu nic do rzeczy.
Błąd trigguje zwykłe conan install i cmake .. przy budowaniu zależności.
Zaciąganie libów i budowanie projektu to dopiero następny etap. CMakeList jest prosty jak budowa cepa - tam nic nie da się zepsuć bo jest tego za mało. To siada nawet na pustym projekcie. Po prostu...

Czekaj, to zacznijmy od początku. Problem masz nie z dołączeniem biblioteki importowanej z conan-a, tylko z wygenerowaną przez conan-a konfiguracją toolchana ?

Czy możesz opisać krok po kroku co instalujesz (wersja, link) i jakie polecenia uruchamiasz ? Bez tego będziemy tylko zgadywać...

Nadal więcej pytań niż odpowiedzi bo konkretów brak:

Sorry, ale ten błąd pojawia się nawet w pustym projekcie.

Tylko "Sorry" jest oczywiste, bo nie ma przykładu jak Twój pusty projekt wygląda i jak go używasz , co tutaj może pójść źle:

• blednę parametry uruchamiania
• błędy w zmiennych środowiskowych
• błędy w środowisku kompilacji (np. stare cmake)
• błędy w plikach

Przy pierwszym kontakcie z cmake tez miałem wrażenie że nic nic nie działa ale po dokładnej analizie problem zawsze był po mojej stronie.

Bartłomiej Golenko napisał(a):

Czekaj, to zacznijmy od początku. Problem masz nie z dołączeniem biblioteki importowanej z conan-a, tylko z wygenerowaną przez conan-a konfiguracją toolchana ?

Czy możesz opisać krok po kroku co instalujesz (wersja, link) i jakie polecenia uruchamiasz ? Bez tego będziemy tylko zgadywać...

To jest napisane:
https://4programmers.net/Forum/C_i_C++/361317-problem_z_cmake_conanem_i_visualstudio_2022?p=1848165#id1848165

@Adamek Adam: To nie jest mój pierwszy kontakt z cmake - na linuksie tylko na cmake stawiałem projekty [edit: właściwie to dużą część na qmake, ale wszystko poza qt w cmake]. Bardziej wyjaśnić czym jest pusty projekt nie potrafię od tego co podlinkowałem.

Odpaliłem z ciekawości po mingw i śmiga, tyle że koncertowo wywala się ODBC... Jest zupełnie inna implementacja. Czemu? Bo VC++ != C++. To inny kod. Musiałbym przepisać cały kod bazodanowy.

Commit jest wart tysiąca słów !

SOA#1
https://github.com/mariuszmaximus/4p_361317.git

pusty projekt cmake, conan install .. --build missing , cmake .. , cmake --build .

@Adamek Adam: Hmmmm.... Tu jest inny generator. W dokumentacji było inaczej... Sprawdzę jutro. Może zabangla. Dziś już mam dosyć. btw Dzięki

@Adamek Adam: Nie działa. Buduje się dependency, ale tylko po usunięciu wywołań find_package, ale gdy je usunę, pojawia się problem z brakiem bibliotek i projekt się wywala. Teraz nie widzi nawet gtest.
Ponadto, przestają działać conanowe rzeczy w cmake, tj conan_basic_setup - w Twoim projekcie jest to samo.
Edit: wcześniej chociaż działał google test, teraz nie działa nic... xD

Edit:
Wydaje mi się, że wiem na czym problem polega w poprzednim rozwiązaniu. To jednak nie cmake. Testowałem to. Problem polega na tym, że te liby includują pthread, którego w visualC++ nie ma i tyle. Dorzucenie jakiejś windowsowej wersji spełza na niczym. Po prostu nie działa. Nawet zaciągałem projekt pthreads4w - no i on się buduje i znajduje, ale jak zaciągam np. rabbitmq-c, siada wszystko.

Generator visual_studio upiernicza widoczność funkcji conana w cmake.

(1) inny generator to znaczy jaki ?

Ja już to w kilku postach pisałem. -,- Spójrz w dokumentację conana: https://conan.io/center/gtest?tab=recipe
To nie działa także na Twoim projekcie. Cały conan pada. Z resztą sam zakomentowałeś. Ja widzę, że zamiast sam pisać kod, tłumaczyć muszę coś co napisałem tu już naście razy.

To nie zadziała.
jeśli chcę zmusić vstudio, stracę cmake, bo muszę to na studiowej solucji zrobić. Inaczej jak wejdę w podkatalog i spróbuję w buildzie dependency wyedytować wygenerowaną solucję, nie dzieje się nic. Musiałbym ręcznie edytować plik, a co i gdzie trzeba tam wkleić, nie mam bladego pojęcia.