Windows proj.lib instead of/in additon to proj_<major>_<minor>.lib

[snowman2]

Thoughts on this?
conda-forge/proj.4-feedstock#46

Are there reasons that this has not been done already?

[kbevers]

For the lazy that can't be bothered to click the link (myself including, hence the long answer time):

The linked issue adresses that on Windows the CMake build will output proj_6_1.lib and not proj.lib. This causes problems since packages depending on PROJ need to be updated every time a new version of PROJ is released.

What is common practice on Windows regarding this? Is it always just <name>.lib with no mentioning of the version number? If so, how is compatibility between versions evaluated?

Would it be sufficient (and possible?) to create a symbolic link to the versioned lib-file?

[busstoptaktik]

If so, how is compatibility between versions evaluated?

@kbevers since this is for static linking, at least the case of trying to call new API entries on an old .lib will be diagnosed by the linker at link time. And once the material is statically linked it doesn't matter what you do the the installed .lib, since its relevant parts will have been statically included in the .exe

[kbevers]

Right, so no real consequences of switching to producing a proj.lib file? If so, we should make that change with version 7, as this is somewhat a breaking change.

[JackBoosY]

Hi @kbevers @busstoptaktik , I'm recently upgrading the proj version in vcpkg(PR #7192), and then I found that the name generated by proj in Windows and Unix is inconsistent. Some proj-dependent libraries (such as gdal and liblas) use proj's default library name in windows as proj.lib, which is obviously inconsistent with the generated name.

To solve this problem, we have two ways:

1. Fix the library name generated by proj as proj, but this obviously violates your original intention (refer to cmake/ProjUtilities.cmake: 105).
2. Fix the name of the libraries that depends on proj in each of the erroneous ports.

So, I want to hear from your authors.

Thanks.

[kbevers]

I think we should change the CMake setup so that proj.lib is always created. As far as I can tell it is what most people expect to get.

This is a breaking change of sorts so I would like to wait with this change until the PROJ 7 release next year. If it is desirable to downstream projects to have this change sooner (PROJ 6.2.0) I am happy to accept a PR that implements a proj.lib symlink to the proj_<major>_<minor>.lib fil. Or just a copy of the file - whatever works.