Exported symbols from loader about openxr-sdk-source HOT 9 CLOSED

Planning to switch this to a VisStudio .def file, rather than in-line decorations. It'll be a few weeks before I have time to look at it.

from openxr-sdk-source.

I think it could be solved either way. With in-line decorations, we just need to be careful to not use the macro with declspec(export) on things that shouldn't be exported (the ones at the top of Ryan's list starting with 'Loader')

from openxr-sdk-source.

The inline decorations would also keep things consistent across platforms.

from openxr-sdk-source.

Also, need to do the same export check on the API layers projects.

from openxr-sdk-source.

I've had some difficulty getting this right with inline decorations, mostly due to some of the fxn declarations being in code-gen'd header files. Adding a .def file is slam-dunk easy but doesn't do anything for the linux exports, so I'll take another run at in-lining it.

from openxr-sdk-source.

WIP branch daveh-loader-exports-redux

from openxr-sdk-source.

We're only exporting core functions, right? There's a check at the beginning of the loop through the functions where it figures out if it's core, an extension that's just starting, or an existing extension. Could probably set a "export prefix" variable there (to the export macro or empty string) and use it in the replace later. (On phone so this is all from memory but I'm pretty sure this is the easiest way to do that.)

from openxr-sdk-source.

OK, I've got two approaches here done and ready for discussion by wg

from openxr-sdk-source.

WG consensus was to go with 'core-only' export for now, with an eye towards restricting to the minimal set of 4 in the future (possibly with some additional extension-wrangling helpers). PR #98 is approved, closing this issue.

from openxr-sdk-source.