[slang-verilog] Add new port (version 10.0)

[Tim Paine (timkpaine)]

• Changes comply with the maintainer guide.
• The packaged project shows strong association with the chosen port name. Check this box if at least one of the following criteria is met:
  • The project is in Repology: https://repology.org//versions
  • The project is amongst the first web search results for "" or " C++". Include a screenshot of the search engine results in the PR.
  • The port name follows the 'GitHubOrg-GitHubRepo' form or equivalent Owner-Project form.
• Optional dependencies of the build are all controlled by the port. A dependency is controlled if it is declared an unconditional dependency in vcpkg.json, or explicitly disabled through patches or build system arguments such as CMAKE_DISABLE_FIND_PACKAGE_Xxx or VCPKG_LOCK_FIND_PACKAGE
• 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 brief and accurate. See adding-usage for context. Don't add a usage file if the automatically generated usage is correct.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Exactly one version is added in each modified versions file.

[Javier Matos Denizac (JavierMatosD)]

Thanks for the contribution! As we mentioned in #50176, this port installs a CMake package called slang, but the existing shader-slang port already installs a package with the same name.

vcpkg must follow upstream CMake package names exactly, so we can’t rename or override the package name on our side. The maintainer guide only allows unofficial -unofficial configs when upstream provides no CMake package at all, which isn’t the case here.

Because both ports currently provide the same CMake package name, they can’t coexist in the registry. I will open an issue upstream asking how these two libraries are intended to coexist, or whether they would consider providing distinct package names or aliases. Once upstream clarifies their intended naming, we can update the port accordingly.

[Javier Matos Denizac (JavierMatosD)]

I've opened an issue with upstream MikePopoloski/slang#1710

[Javier Matos Denizac (JavierMatosD)]

I'm going to place in draft while we wait on upstream guidance

[Tim Paine (timkpaine)]

Please link the issue on shader slang as well, thanks for managing this!

[Tim Paine (timkpaine)]

We've established as slang-verilog on conda: https://github.com/conda-forge/slang-verilog-feedstock

[Billy O'Neal (BillyONeal)]

GPT 5.6 Sol reports:

The port still conflicts with shader-slang by exporting slangConfig.cmake and slang::slang. Moving files under share/slang-verilog does not disambiguate the package or target. Upstream approved slang-verilog and slang-verilog::slang.
[...]
Upstream explicitly approved a disambiguated slang-verilog config and a slang-verilog::slang target in that discussion. The current PR does not implement either. Merely moving the first project's config under share/slang-verilog does not change the CMake package filename or exported target identity

[...]

usage recommends slang::slang_slang, but the installed export creates slang::slang. Configuring the documented example failed:

Target "slang_usage_consumer" links to:
 slang::slang_slang
but the target was not found.

vcpkg print-usage slang-verilog:x64-windows-static --generated correctly identified slang::slang, so the custom file should at minimum be removed in favor of generated usage. The final usage must instead reflect the disambiguated package/target required by the preceding finding.

I'm not sure about this part but I'm repeating it here because it might be helpful for you:

AnalysisManager.h publicly includes BS_thread_pool.hpp when SLANG_USE_THREADS is exported, but the port neither installs that header nor declares bshoshany-thread-pool. The bundled copy is also used during compilation, leaving an undeclared public dependency and vendored third-party code.

This is observable in an ordinary CMake consumer:

.../include/slang/analysis/AnalysisManager.h(11): fatal error C1083:
Cannot open include file: 'BS_thread_pool.hpp': No such file or directory

The bundled external/BS_thread_pool.hpp is also used to compile slang itself (SourceLoader.cpp) and is a well-known third-party library already packaged as bshoshany-thread-pool. This conflicts with the [registry] rule against building with vendored third-party code.