search

OSGeo / PROJ

PROJ - Cartographic Projections and Coordinate Transformations Library
https://proj.org
Other
1.67k stars 752 forks source link

CMake: for Windows builds, name proj DLL just 'proj.dll', except on mingw where it will be 'proj-{soname}.dll' #4167

Open rouault opened 3 weeks ago

rouault commented 3 weeks ago

Fixes #4151 . Aligns with GDAL PR https://github.com/OSGeo/gdal/pull/5701

@hobu Any opinion regarding that ? Current behaviour of having 'proj_X_Y.dll' comes from the initial CMake commit of yours 532a0f5408 from 10 years ago.

rouault commented 1 day ago

@kbevers any opinion w.r.t this change?

kbevers commented 1 day ago

I'm not sure I've understood the change. Currently on Windows we produce a DLL called proj.dll except when using MingW where you instead get proj_9_4.dll, correct? And this changes the MingW-dll's name to be based on the soname, making it proj_25.dll (or whatever the current soversion is), yes?

Assuming I've understood that correctly, I think this looks like a change that will break peoples workflows. Probably not too many people are relying on MingW but some will for sure and I don't think we can just change things willy-nilly. Would it be possible to create to versions of the DLL, one with the current name and one with the proposed name? That would keep backwards compatibility, at least.

rouault commented 1 day ago

currently on Windows we produce a DLL called proj.dll except when using MingW where you instead get proj_9_4.dll, correct?

no, we produce proj_9_4.dll for both MSVC and MinGW currently. This PR changes to "proj.dll" for MSVC and "proj-{soname}.dll" for MinGW.

I think this looks like a change that will break peoples workflows

yes, possibly

Would it be possible to create to versions of the DLL, one with the current name and one with the proposed name?

Hum, this would complicate things a bit more than what I'd like, and would probably cause some confusion. If we are not ready for that change in the 9.x series, it would probably be better to just drop it for now. Or maybe had a CMake variable PROJ_NEW_DLL_NAME=ON/OFF ? PROJ_10_COMPATIBLE_DLL_NAME=ON/OFF ?

kbevers commented 1 day ago

I think a CMake variable that switches to a future PROJ 10 behaviour is a good solution. If you don't do anything you'll get the same as always and if you ask for it you get the improved naming suggested in this PR.

In PROJ 10 we can then get rid of the current naming scheme for Windows builds.