-
Notifications
You must be signed in to change notification settings - Fork 837
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Determine libSPIRV target 'public' interface #2308
Comments
Right, the AST -> SPIR-V generator is not based on a publicly supported interface, nor did this project ever say it was or say it should be an SO or advise that Linux distributors distribute it that way. This project intended a few small static libraries to have their necessary smaller subsets pulled into parent projects, either into a parent's static library or a parent's SO. As you note, the So, we don't need to do 1. |
At the moment the proposed public interface to SPIRV is basically all the symbols declared in |
The symbols tagged with GLSLANG_EXPORT in #3705 are the proposed public interface to the |
As part of the work to apply Semantic Versioning to the glslang project, we need to determine what we consider as part of the public, stable API and what is internal.
The Semantic Versioning introduction states:
For the
glslang
target we have been able to classifyglslang/Public/ShaderLang.h
as the public API. This is now (#2303) enforced through defaulting to-fvisibility=hidden
and only making public the methods and types annotated withGLSLANG_EXPORT
.libSPIRV
is another library that is already found in linux distribution packages, but AFAICT, there is no clear separation between the public and private interface. As such, any changes to theSPIRV
source files will likely require a major semantic version bump, which severely reduces the benefits for semantic versioning.I see a few options:
We spend the time to try classifying the public interface, and build a
SPIRV/Public/SPIRV.h
file, similar toglslang
.Remove
libSPIRV
from the 'public' interface.It's hard to know how many people out there are using the
libSPIRV
target - but one potential solution is to make this an entirely 'private' library, and ensure this is statically linked into theglslangValidator
executable, removing it from the install target. This would remove it from existing linux distributions, breaking anyone who is currently depending on it.We simply ignore semantic versioning for
libSPIRV
. Breaking API changes tolibSPIRV
are not considered for major version bumping. Semantic versioning will only apply for theglslang
target.Feedback and opinions welcome.
The text was updated successfully, but these errors were encountered: