WFA headers and libs may cause conflict

[outpaddling]

Does vcflib actually require WFA2 headers and libraries at runtime?
As installed by 1.0.6, they will conflict with separately installed WFA2, which might be installed independently as a dependency of some other package.
If they must be installed for vcflib runtime to function, I would suggest installing them under a vcflib subdirectory to prevent conflicts.

[pjotrp]

What are you using? Are you building by hand?

[outpaddling]

No, I'm updating the FreeBSD port. When updating to 1.0.6, I noticed that your cmake build system installs WFA2-lib headers and libraries under the standard prefix as part of the vcflib install. To resolve the potential conflict, I have unbundled WFA2-lib from vcflib so it's installed by a separate port, which is a dependency of the vcflib port.

CMAKE_ARGS+= -DWFA_GITMODULE=OFF -DWFALIB=${LOCALBASE}/lib/libwfa2.so

But I wonder if installing the WFA2-lib files via the vcflib build was intentional on your end, or just an oversight.

[pjotrp]

Hmm. With WFA_GITMODULE=OFF nothing should install.

[pjotrp]

I'll fix it.

[outpaddling]

It doesn't. WFA_GITMODULE=OFF is part of my fix to unbundle WFA2-lib. What I'm asking is if you intended to install the WFA2-lib files by default, where the user has not explicitly disabled WFA_GITMODULE.

[pjotrp]

Yeah, that is intentional. Though I could statically link wfa2lib when using git submodules. And people don't really need include files.

[outpaddling]

Yeah, that's the traditional approach when using bundled dependencies, both to avoid install conflicts and ambiguity where there may be multiple wfa2 libs in the link path. Not an immediate concern for me since I already committed the unbundled wfa2-lib and vcflib FreeBSD ports, but using the static lib and not installing libs or headers will probably save someone a headache down the road.