lib prefix on Windows

[diorcety]

Is there any convention related to lib prefix for zproject on Windows.

Because by default in cmake for a library target called mlm on Windows the output file is mlm.dll and on linux it's libmlm.so

The issue is that project.libname is always prefixed by lib

project.libname is defined here

zproject/zproject.gsl

Line 51 in de9a672

project.libname ?= "lib" + project.linkname

project.libname is used in python binding for finding the library

Shouldn't we use something like that?

set_target_properties(mlm PROPERTIES
    OUTPUT_NAME "mlm"
    PREFIX "lib")

[bluca]

I think one issue is backward compatibility - if the filename changes, there's a good chance all existing projects that use it will break

[jimklimov]

Well, the breakage mode needs that a project is regenerated. And users should review (git diff) or PR (and web-review) the changes. Also GSL can echo a warning about such change - though it does warn about many things that might bite you (they really can, so notice is not worthless).

Another breakage may be that projects which use your component (say mlm.dll as deliverable) can get broken by your upgrade and might have to rebuild. Or... as a legacy fallback you might add a rule (simple cp or ln equivalent, maybe optional) so you build and deliver both mlm.dll and libmlm.dll. For an ecosystem like our FTY project we can just rebuild all components and no longer deliver legacy filenames. Lower-level projects like mlm might have to serve both in make install and packaging on affected platforms.

Sent from my Xiaomi Redmi Note 4 using FastHub

[bluca]

Yeah the problem is external reverse dependencies, that do not use zproject. Having a backward compatibility link could work as a solution

[diorcety]

About prefix I'm not sure but it seems that CMake don't put the prefix with MSVC not with MSYS or MINGW. It seems that nobody try the mlm/czmq python binding with MSVC toolchain.