Open wolfv opened 1 month ago
Isuru pointed out on Element:
A common pattern is foo.lib and foo.0.17.dll which are equivalent to libfoo.so and libfoo.so.0.17 in linux
Another common pattern from GMP:
- test ! -f ${PREFIX}/lib/libgmp.a # [unix]
- test -f ${PREFIX}/lib/libgmp.dylib # [osx]
- test -f ${PREFIX}/lib/libgmp.so # [linux]
- test ! -f ${PREFIX}/lib/libgmpxx.a # [unix]
- test -f ${PREFIX}/lib/libgmpxx.dylib # [osx]
- test -f ${PREFIX}/lib/libgmpxx.so # [linux]
- if not exist %LIBRARY_BIN%\libgmp-10.dll exit 1 # [win]
- if not exist %LIBRARY_LIB%\libgmp.dll.a exit 1 # [win]
- if not exist %LIBRARY_LIB%\gmp.lib exit 1 # [win]
but is it common to have the lib
file with these .0.0.17
? i don't think so right?
I'd say that most of the time there is no version in the .lib filename. When there is a version, it's usually in the form mylib-2.lib
.
FWI, i patched out the "lib" in the offending project and requested input from upstream https://github.com/aous72/OpenJPH/issues/155
@jaimergp can we use your tool to run a query for the names of all *.dll
and *.lib
files in the conda-forge universe?
I am not sure if enforcing a naming rule makes a lot of sense. I imagine that, if the CMake find_package works correctly, things will be found no-matter-what their name ends up.
So we could also change the regex to something like foo*.dll
and foo*.lib
...
can we use your tool to run a query for the names of all .dll and .lib files in the conda-forge universe?
The sqlite dumps are downloadable for this kind of large query that wouldn't be efficient in a public server. Some links:
The openjph package installs dll / lib files with a ABI version like
foo.0.17.dll
andfoo.0.17.lib
.Should we support that?