glslang: Only export public interface for SOs

[ben-clayton]

Default to -fvisibility=hidden, and annotate the public glslang interface with GLSLANG_EXPORT to change the visibility of these cherry-picked symbols to default.
This is also used by Windows builds for __declspec(dllexport)-ing the public DLL interface.

This allows us to classify API changes into those that are publicly backwards compatible, and those that are not.

Note that libSPIRV will likely need similar treatment.

[johnkslang]

This move seems a bit odd, because these seem like an internal interface, not a public interface.

I'll try to say more in the main conversation.

[johnkslang]

This generally looks quite good. I'm a bit worried about "which" interface is being dealt with.

I think maybe there are two levels of interface to maintain:

1. an external high level, non-internals, interface: here's my shader text, validate it, translate it to SPIR-V, etc. level
2. internal lower level, I want to process the AST myself interface

And possibly two more that got added that we might want to consider distinct from interface 2:

3. reflection
4. io mapping

The original scheme was that only interface 1 existed, it was to be captured in ShaderLang.h, and that's why that header is in the public subdirectory. Interface 2 needs a bunch of stuff like type and node information, which is in headers not in the public subdirectory.

I'd consider interfaces 1 and 2 as the primary Khronos-provided tools to do GLSL validation and GLSL -> SPIR-V translation of valid GLSL. The other interfaces are more kind of side projects and more maintained by the community.

So, one thing that's a red flag in this PR is moving something I think is in interface 2 (TLayoutPacking) into interface 1. I might be wrong about it and am just trying to progress the discussion, but that's one specific thread to pull to see how things unravel.

It could be that only interface 1 is what needs to be subjected to the SO rigor, and that people using the other interfaces do things more from a static library perspective.

[ben-clayton]

I agree.

Due to versioning practicality, I feel that interface 1. is the only one we're going to sensibly provide as a versioned, shared library right now. Interface 2 has no separation of stable-public from anything else (AFAICT), which would mean touching pretty much any internal function or struct would technically require a major version bump. This seems impractical, but there's nothing stopping us trying to define a public and stable internal interface (2) over time.

So, one thing that's a red flag in this PR is moving something I think is in interface 2 (TLayoutPacking) into interface 1. I might be wrong about it and am just trying to progress the discussion, but that's one specific thread to pull to see how things unravel.

Agreed. I wasn't really sure what to do with this. getMemberAlignment() uses this enum, which in turn is used by libSPIRV.
Do you have any suggestions to break this transitive dependency so we can keep TLayoutPacking private?

[johnkslang]

What makes getMemberAlignment() stand out differently than all the other TIntermediate and TType stuff that should be needed for interface 2, but not for interface 1?

[ben-clayton]

What makes getMemberAlignment() stand out differently than all the other TIntermediate and TType stuff that should be needed for interface 2, but not for interface 1?

A good question, and clearly this is broken. We get away with these not being made public as Tintermediate and TType being mostly inline, but yes, there's an ABI contract here that I'm completely ignoring.

I'm going to have to thing hard about these.

[ben-clayton]

Closing this PR. I have another approach in the works to resolve the libglslang <-> libSPIRV dependency issue.