[blpapi] add new port

[sweemer]

• Changes comply with the maintainer guide
• The name of the port matches an existing name for this component on https://repology.org/ if possible, and/or is strongly associated with that component on search engines.
• Optional dependencies are resolved in exactly one way. For example, if the component is built with CMake, all find_package calls are REQUIRED, are satisfied by vcpkg.json's declared dependencies, or disabled with CMAKE_DISABLE_FIND_PACKAGE_Xxx
• The versioning scheme in vcpkg.json matches what upstream says.
• The license declaration in vcpkg.json matches what upstream says.
• The installed as the "copyright" file matches what upstream says.
• The source code of the component installed comes from an authoritative source.
• The generated "usage text" is accurate. See adding-usage for context.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is in the new port's versions file.
• Only one version is added to each modified port's versions file.

Disclaimer: I am not affiliated with Bloomberg in any way. I am simply adding this port based on their publicly available libraries.

I have two questions:

1. Their license looks like MIT but I don't think I should be the one to say for sure. Can we leave the license declaration blank until we can get somebody from Bloomberg to clarify?
2. Bloomberg only provide dynamic libraries, so I have reflected that in the supports field; however, I would like to remove that restriction and force dynamic linkage even when the user is using a static triplet. Can you guide me on how to do that?

[JonLiu1993]

Suggested change

	"dependencies": [
	{
	"name": "vcpkg-cmake",
	"host": true
	},
	{
	"name": "vcpkg-cmake-config",
	"host": true
	}
	]

[JonLiu1993]

@sweemer, Thanks for your PR, vcpkg_cmake_configure and vcpkg_cmake_install provided by vcpkg-cmake port
vcpkg_cmake_config_fixup provided by vcpkg-cmake-config port, blpapi does not use these functions, so "vcpkg-cmake" and "vcpkg-cmake-config" should not be used

[sweemer]

Done

[JonLiu1993]

Tested usage successfully by blpapi:x64-windows:

The package blpapi provides CMake targets:

    find_package(blpapi CONFIG REQUIRED)
    target_link_libraries(main PRIVATE blpapi)

[JonLiu1993]

Note: I will be converting your PR to draft status. When you respond, please revert to "ready for review". That way, I can be aware that you've responded since you can't modify the tags.

[BillyONeal]

I checked that the DLLs don't appear to link with a CRT so this debug release mismatch might be OK.

[BillyONeal]

Their license looks like MIT but I don't think I should be the one to say for sure. Can we leave the license declaration blank until we can get somebody from Bloomberg to clarify?

LGTM

Bloomberg only provide dynamic libraries, so I have reflected that in the supports field; however, I would like to remove that restriction and force dynamic linkage even when the user is using a static triplet. Can you guide me on how to do that?

It would literally just be removing that block from the supports clause. The problem is that dynamic linkage with static CRT is usually doom so we intentionally don't make that easy to do out of the box.

[BillyONeal]

Please double check that you're happy with nitpicks I fixed, and if so, indicate that you are happy by marking this 'Ready for review'

[sweemer]

@BillyONeal I'm happy with the changes you've made.

Regarding forced dynamic linkage, do I understand correctly that you don't recommend forcing it with a static triplet? If so, then I will leave it the way it is. But if it's acceptable in this case then I would like to remove that part of the supports clause before merging. If the concern is about dynamic linkage with static CRT then I don't mind changing it to something like (linux | (windows & !uwp)) & !(!static & staticcrt) & (x86 | x64).

[BillyONeal]

Regarding forced dynamic linkage, do I understand correctly that you don't recommend forcing it with a static triplet?

You can force dynamic linkage with a static triplet if the resulting DLL doesn't speak about the standard library at all. Most libraries aren't prepared to deal with, for example, std::vector&s that you can't use because they belong to a totally different CRT.

There are global variables like the debug lock or the locale lock which cause doom if you try to touch standard library components visibly across such an interface. When you dynamically link with the CRT, those global variables live in the CRT's DLLs, but a static triplet requests a static CRT. Static CRT plus dynamic linkage means each DLL has its own CRT, and thus its own copy of those globals, and thus can't contain standard library types in their interface at all.

[apollomok]

Is the path out-dated? vcpkg cannot download from the path.

error: https://bcms.bloomberg.com/BLPAPI-Generic/blpapi_cpp_3.20.2.2-windows.zip: WinHttpSendRequest failed with exit code 12007

[sweemer]

Yes, it might need to be updated. I can take a look next week.

[sweemer]

Updated in #40130