[beman-exemplar] new port

[wusatosi]

• 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.

CC @bretbrownjr

[wusatosi]

Generated file structure:

<need update>

[wusatosi]

Relevant logs on failures from x64-windows:

CMake Error at scripts/cmake/vcpkg_execute_build_process.cmake:134 (message):
    Command failed: D:/downloads/tools/cmake-3.30.1-windows/cmake-3.30.1-windows-i386/bin/cmake.exe --build . --config Debug --target install -- -v -j33
    Working Directory: D:/b/beman-exemplar/x64-windows-dbg
    See logs for more information:
      D:\b\beman-exemplar\install-x64-windows-dbg-out.log

install-x64-windows-dbg-out.log:

C:\PROGRA~1\MICROS~1\2022\ENTERP~1\VC\Tools\MSVC\1443~1.348\bin\Hostx64\x64\cl.exe   /TP  -ID:\b\beman-exemplar\src\2.0.0-bb1eb5023d.clean\include /nologo /DWIN32 /D_WINDOWS /utf-8 /GR /EHsc /MP  /MDd /Z7 /Ob0 /Od /RTC1  -MDd /showIncludes /Foexamples\CMakeFiles\beman.exemplar.examples.identity_direct_usage.dir\identity_direct_usage.cpp.obj /Fdexamples\CMakeFiles\beman.exemplar.examples.identity_direct_usage.dir\ /FS -c D:\b\beman-exemplar\src\2.0.0-bb1eb5023d.clean\examples\identity_direct_usage.cpp
D:\b\beman-exemplar\src\2.0.0-bb1eb5023d.clean\include\beman/exemplar/identity.hpp(25): error C2429: language feature 'nested-namespace-definition' requires compiler flag '/std:c++17'
[3/7] C:\PROGRA~1\MICROS~1\2022\ENTERP~1\VC\Tools\MSVC\1443~1.348\bin\Hostx64\x64\cl.exe   /TP -DGTEST_LINKED_AS_SHARED_LIBRARY=1 -ID:\b\beman-exemplar\src\2.0.0-bb1eb5023d.clean\include -external:ID:\installed\x64-windows\include -external:W0 /nologo /DWIN32 /D_WINDOWS /utf-8 /GR /EHsc /MP  /MDd /Z7 /Ob0 /Od /RTC1  -MDd /showIncludes /Fotests\beman\exemplar\CMakeFiles\beman.exemplar.tests.identity.dir\identity.test.cpp.obj /Fdtests\beman\exemplar\CMakeFiles\beman.exemplar.tests.identity.dir\ /FS -c D:\b\beman-exemplar\src\2.0.0-bb1eb5023d.clean\tests\beman\exemplar\identity.test.cpp
FAILED: tests/beman/exemplar/CMakeFiles/beman.exemplar.tests.identity.dir/identity.test.cpp.obj 
C:\PROGRA~1\MICROS~1\2022\ENTERP~1\VC\Tools\MSVC\1443~1.348\bin\Hostx64\x64\cl.exe   /TP -DGTEST_LINKED_AS_SHARED_LIBRARY=1 -ID:\b\beman-exemplar\src\2.0.0-bb1eb5023d.clean\include -external:ID:\installed\x64-windows\include -external:W0 /nologo /DWIN32 /D_WINDOWS /utf-8 /GR /EHsc /MP  /MDd /Z7 /Ob0 /Od /RTC1  -MDd /showIncludes /Fotests\beman\exemplar\CMakeFiles\beman.exemplar.tests.identity.dir\identity.test.cpp.obj /Fdtests\beman\exemplar\CMakeFiles\beman.exemplar.tests.identity.dir\ /FS -c D:\b\beman-exemplar\src\2.0.0-bb1eb5023d.clean\tests\beman\exemplar\identity.test.cpp
D:\b\beman-exemplar\src\2.0.0-bb1eb5023d.clean\include\beman/exemplar/identity.hpp(25): error C2429: language feature 'nested-namespace-definition' requires compiler flag '/std:c++17'
ninja: build stopped: subcommand failed.

[wusatosi]

@microsoft-github-policy-service agree

[wusatosi]

@nickelpro make us great

[wusatosi]

I did some digging, error comes down to these:

x64_windows/ x84_windows/ x64_uwp:

D:\a\_work\1\s\ports\beman-exemplar\portfile.cmake: warning: Import libraries for installed DLLs appear to be missing. If this is intended, add set(VCPKG_POLICY_DLLS_WITHOUT_LIBS enabled)
D:\a\_work\1\s\ports\beman-exemplar\portfile.cmake: warning: the following DLLs were built without any exports. DLLs without exports are likely bugs in the build script. If this is intended, add set(VCPKG_POLICY_DLLS_WITHOUT_EXPORTS enabled)
D:\p\beman-exemplar_x64-windows: note: the DLLs are relative to ${CURRENT_PACKAGES_DIR} here
note: debug/bin/debug/beman.exemplar.dll
note: bin/beman.exemplar.dll
D:\a\_work\1\s\ports\beman-exemplar\portfile.cmake: warning: There should be no installed empty directories. Empty directories are not representable to several binary cache providers, git repositories, and are not considered semantic build outputs. You should either create a regular file inside each empty directory, or delete them with the following CMake. To suppress this message, add set(VCPKG_POLICY_ALLOW_EMPTY_FOLDERS enabled)
D:\p\beman-exemplar_x64-windows: note: the directories are relative to ${CURRENT_PACKAGES_DIR} here
note: file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/debug/lib/debug" "${CURRENT_PACKAGES_DIR}/lib")
D:\a\_work\1\s\ports\beman-exemplar\portfile.cmake: warning: Found 3 post-build check problem(s). These are usually caused by bugs in portfile.cmake or the upstream build system. Please correct these before submitting this port to the curated registry.
error: building beman-exemplar:x64-windows failed with: POST_BUILD_CHECKS_FAILED

I have no expertise here, @nickelpro @bretbrownjr can you come and see if the DLL thing is a desired behavior?

[nickelpro]

It's not, Beman needs to decide on a policy for how we're going to handle symbol export. We're relying on the default behavior of *Nix platforms of the moment.

[nickelpro]

Oh but for exemplar it is. Why does exemplar even produce a library? Just to demonstrate how it's done?

[bretbrownjr]

Yes. It's an example and a project template. The other beman projects will use this as a starting point.

[nickelpro]

Sure but exemplar doesn't export anything, and therefore isn't demonstrating how to export anything. Exemplar isn't using WINDOWS_EXPORT_ALL_SYMBOLS or prefixing a symbol with __declspec(dllexport) or __attribute__ ((visibility ("default"))).

Exemplar should have something in it that says, "and if you need to export a symbol this is how you do it". That would fix this bug and serve exemplar's purpose of being a demonstrator for other Beman projects.

[nickelpro]

Anyway, none of this is vcpkg's fault and this isn't a vcpkg discussion. Recommend benching this until we figure this out upstream. Nominally this problem can be solved with VCPKG_POLICY_DLLS_WITHOUT_LIBS but I don't think that's a good answer.

[wusatosi]

Sure but exemplar doesn't export anything, and therefore isn't demonstrating how to export anything. Exemplar isn't using WINDOWS_EXPORT_ALL_SYMBOLS or prefixing a symbol with __declspec(dllexport) or __attribute__ ((visibility ("default"))).

Exemplar should have something in it that says, "and if you need to export a symbol this is how you do it". That would fix this bug and serve exemplar's purpose of being a demonstrator for other Beman projects.

It is not appropriate to discuss here, but there's a scope question on what exactly beman.exemplar is, because if it's just a bootstrap template library, I think it's very likely that beman will be shipping header only libraries or libraries that is essentially a series of templated struct definitions that won't produce significant symbol tables for the majority of its use case.

[dg0yt]

AFAIU this should be just header-only, exporting a CMake interface target.

[nickelpro]

If this were a real library, I would agree.

Honestly I don't even think this belongs in the builtin registry. Beman can maintain it's own registry for things like exemplar. There's no reason anyone would want exemplar as a dependency, it's purely a template/demo repo.

Recommend closing this and we can revisit with the actually useful Beman repos.

[wusatosi]

If this were a real library, I would agree.

Honestly I don't even think this belongs in the builtin registry. Beman can maintain it's own registry for things like exemplar. There's no reason anyone would want exemplar as a dependency, it's purely a template/demo repo.

This is in principle serve as an example of how beman projects based on exemplar would look like when they're published. I think for consistency and model service there is value in pushing this to central.

[dg0yt]

It doesn't need to be in vcpkg's curated registry to serve as an example.
If it is implemented in canonical CMake, it doesn't add much value to the generic CMake example.

In addition, it is not a good example when its implementation (binary lib) doesn't match its nature (header-only).

[dg0yt]

Which symbols are provided by the DLLs, and how are they used?