[lwlog] Added new library

[ChristianPanov]

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

[ChristianPanov]

@microsoft-github-policy-service agree

[Cheney-W]

I have two more questions:

1. Does the built lwlog_sandbox.exe need to be provided to users?
2. The current storage structure of the header files causes them to be included in the form <src/xxx.h>. Is this the expected behavior?

[ChristianPanov]

@Cheney-W Regarding your first question, actually no, maybe I should make some changes to the cmake, but sandbox shouldn't neccessarily come with the library.
And yes, this file structure is intentional, to have all headers and compilation units in the same place

[dg0yt]

AFAICT this must not be in this port, given its binary artifacts.

set(VCPKG_BUILD_TYPE release)
set(VCPKG_POLICY_MISMATCHED_NUMBER_OF_BINARIES enabled)

[dg0yt]

2. The current storage structure of the header files causes them to be included in the form <src/xxx.h>. Is this the expected behavior?

And yes, this file structure is intentional, to have all headers and compilation units in the same place

It is fine to organize everything in src/ in the source directory. But what looks questionable is the use of include/src/ in the installed tree. It doesn't give any hint that src is "owned" by lwlog, and it would clash with other packages making the same choice for directory and file names. In that regard, it is not much better then putting everything directly into include/.
With the CMake config available, where is the problem with installing header e.g. to include/lwlog/? Do you need help with that?

[ChristianPanov]

2. The current storage structure of the header files causes them to be included in the form <src/xxx.h>. Is this the expected behavior?

And yes, this file structure is intentional, to have all headers and compilation units in the same place

It is fine to organize everything in src/ in the source directory. But what looks questionable is the use of include/src/ in the installed tree. It doesn't give any hint that src is "owned" by lwlog, and it would clash with other packages making the same choice for directory and file names. In that regard, it is not much better then putting everything directly into include/. With the CMake config available, where is the problem with installing header e.g. to include/lwlog/? Do you need help with that?

I fully agree. Just pushed the changes