faced with the problem THREADS_PTHREADS version 3
the fact is that most people use the old version, new does not see, even with a wrapper
if you specify explicitly then everything works
but there are projects that explicitly link by library name
OPTIONS_DEBUG # automatic templates
-DLIBUSB_LIBRARIES=${CURRENT_INSTALLED_DIR}/debug/lib/libusb-1.0.lib
-DTHREADS_PTHREADS_WIN32_LIBRARY=${CURRENT_INSTALLED_DIR}/debug/lib/pthreadVC2.lib
OPTIONS
-DLIBUSB_LIBRARIES=${CURRENT_INSTALLED_DIR}/lib/libusb-1.0.lib
-DTHREADS_PTHREADS_WIN32_LIBRARY=${CURRENT_INSTALLED_DIR}/lib/pthreadVC2.lib
example
https://github.com/steve-m/librtlsdr
had to symbolic link pthreadVC3.lib -->> pthreadVC2.lib
Instead of patching our pthread v3 portfile to rename/copy pthreadVC3.lib —> pthreadVC2.lib, do you think it would be impossible to fix the problem upstream in the libraries that still expect the ancient v2?
no copy, symbolic reference ))
you have to write a script wrapper ((
alias?
What do you mean with symbolic references? If it is a file link, unfortunately before win10 1803 and even then without developer mode enabled, it requires admin privileges and so it’s out of question.
In any case any “double entry” to the same file would cause maybe some problems with vcpkg auto linking for vs solutions (same symbol in different libs)
Can you tell me in that project exactly where is the wrong pthread linking line? Maybe it’s not easy to locate? What about patching that project so to be pthreadVC* version independent?
for a personal directory that is not created as an administrator, you do not need any privileges to create a symbolic link
and if many people work with one project, then in any case there are permissions to record
and this is not the only project, there are about 8 of them, which I faced
In these 2 lines the explicit “2” must be changed maybe to a version symbol
for a personal directory that is not created as an administrator, you do not need any privileges to create a symbolic link
What os version do you use? To create symbolic links in Windows you had always needed admin privileges, even if you were working in your home folder. Things changed one year ago, but still you had to opt-in in the new mechanism (developer mode)
I just voiced the problem that many face, in more detail I do not have time to figure out
I go for less resistance
\sorry google translate
_windows 1803_
ver
Microsoft Windows [Version 10.0.17134.345]
That’s exactly what I look for: least resistance. And that maybe means just a copy of the file, from VC3 to VC2, apart from the symbolic redundancy that may create.
@ras0219-msft what do you think?
Stupid question: Can you not simply delete the FindThreads module and use CMakes buildin FindThreads module and set THREADS_PREFER_PTHREAD_FLAG?
worth a try, just remove the module
_\google translator smiles_
@Neumann-A
Is it possible to set a priority in the search for modules?
suppose, search first in VCPKG then in CMAKE share MODULE and last with the project files?
Can you not simply delete the FindThreads module and use CMakes buildin FindThreads module and set THREADS_PREFER_PTHREAD_FLAG?
CMake integrated thread module doesn’t look for posix thread implementations on Windows afaik, no matter how much hard you ask for them. I had also to write a custom module for darknet/yolo back in the time, but I didn’t overlay the official one. I can understand the problem that pthreadVC2 has been there for a long time, i’d patch problematic projects to bring them to the modern age, but still can also understand replicating files, if it’s so simple and fixes many projects in a glimpse.
Is it possible to set a priority in the search for modules?
That’s what CMAKE_MODULE_PATH is there for
That’s what CMAKE_MODULE_PATH is there for
it is understandable, globally in VCPKG
What is the default priority in the CMAKE?
This is the order CMake follows: First of all, look in the folders in that path (in the order they are written), then look in the internal repository (share/cmake-x.y/Modules).
vcpkg does not have a single module folder, each port writes its own module in its share folder (similar to the config mode)
Well, as implemented in meson dependency search via cmake
https://github.com/microsoft/vcpkg/pull/6977#issuecomment-504146129
example
"C:/Program Files/cmake/bin\cmake.EXE" -G "Visual Studio 10 2010" --trace-expand -DNAME=libelf -DARCHS= -DCMAKE_PREFIX_PATH=E:/tools/vcpkg/installed/x64-windows .
The root folder x64-windows .
modules are default
folder root Cmakeor lib/Cmake
installed/x64-windows/Cmake
installed/x64-windows/lib/Cmake