The change states the Fortnite client was used to judge which individual methods should still be exported.
Unfortunately this isn’t quite good enough, because you’ll have licensee code that used exposed methods that Epic internally may not have been used - resulting in the stated linker errors. Inadvertently public APIs from plugins have been broken with this change.
While we can handle this on our end by exporting these functions again, this means engine changes and no guarantee of future breakages. Should any public symbols in public headers always be exported? (Though this definitely hasn’t always been the case in the engine, and generally that’s ok. But I don’t think we’ve had a situation before where symbols had their export status revoked between engine versions, or at least not without a clear deprecation phase or a different way to get to the desired functionality.)
Steps to Reproduce
Have a project in 5.5 that uses a previously exposed method from a separate plugin, such as `UPCGSplineProjectionData::GetSpline` (exported due to `PCG_API` on the parent class `UPCGProjectionData`), and then try to compile under 5.6. Linker errors will occur.
Considering the GetSpline method here is a convenience function and that we’ve purposefully not exposed the Source in the PCG Projection Data, this is really intended behavior.
That GetSpline method not being dll exported should not have anything to to do with the change where we move dllexport from type to methods/static vars.
The large scripted change should not remove dll export on anything that was previously exported. It was made to fix the issue where lots of (especially implicitly generated) functions/staticvar were _both_ inline and having dllstorage. This caused issues internally with some of our new ways of building code and had to be addressed.
If there were removed dllstorage somewhere that was unintentional and should be fixed, please report those and I apologize in advance.
I will keep a note for the UPCGMeshSelectorByAttribute - I think the initial goal was to not necessarily to make this one extensible, but we’ll review.
FWIW, the GetSpline if you do need it, you should have the spline in its original data form elsewhere (data workaround - you had that spline when you created the projection) or you can change the GetSpline locally (code-wise).
We use it from a separate plugin just fine in 5.5. It’s a public class function that is exported (our code links, so it must be the case) and the most likely reason it is is because of the PCG_API on the parent class? Maybe it wasn’t intended to be exported, but we could definitely link to it.
We have a custom PCG node that can take a spline and use it to fit meshes to. It gets transforms from the spline data to do the placement. I’ll ask the team members that wrote this code tomorrow for some more details.
I have to stand corrected. Potentially I’m performing a more thorough recompile of our custom modules, but it looks like the plugin in question doesn’t build under 5.5 either. I’ll continue the investigation on our end. Probably shouldn’t have posted late on a Friday!
Got this from the team as to what the use case was. It is a bit older code which is likely why it worked before:
“If I remember correctly it was a PCG node that placed spline shapes along another spline with “collision” so there was no overlapping shapes. Think it needed access to the spline data to do the collision checks.”
Apologies, as mentioned above, a combination of CI not picking up our plugins in one configuration and one project having manually added export definitions to some methods made the mentioned change appear to be the most likely culprit for linking errors.
Talking about extendibility, if UPCGMeshSelectorByAttribute is intended to be extended in the same way UPCGMeshSelectorBase is - some export definitions are needed there as well.
Looking a little bit closer at our use case for GetSpline, it was basically to replicate the functionality of PCGSplineSamplerHelpers::GetPolyLineData (which sits in a public header as well). Does it make more sense to export the functionality of that helper class officially?