Errors in SPiiPlusAuxDriver.cpp prevent it from building correctly on Windows dynamic

[MarkRivers]

SPiiPlusAuxDriver.cpp contains these lines:

#include <epicsThread.h>
#include <epicsExport.h>

#include <asynPortDriver.h>

#include "SPiiPlusAuxDriver.h"

This is incorrect because epicsExport.h is included before code that defines things in other libraries. epicsExport.h must be followed only by includes that will be in the library being built in this module. The compile errors are actually for asynMotorController, because that is indirectly included by SPiiPlusAuxDriver.h,

I believe the correct code is:

#include <epicsThread.h>

#include <asynMotorController.h>
#include <asynMotorAxis.h>

#include <epicsExport.h>

#include "SPiiPlusAuxDriver.h"

Note that it is not necessary to include asynPortDriver.h because that is included by asynMotorController.h.

I have not tested my solution, it may be that there are other things that need to be included before epicsExport.h as well.

[MarkRivers]

The error building was from Tim Speight who is building in the Visual Studio IDE, not with EPICS build system.

I just tried building AcsMotion on windows-x64 (e.g. dynamic) and to my surprise it built OK. I made this fix so the class would be exported in the dll:

diff --git a/acsMotionApp/src/SPiiPlusAuxDriver.h b/acsMotionApp/src/SPiiPlusAuxDriver.h
index 98bf872..039ea13 100644
--- a/acsMotionApp/src/SPiiPlusAuxDriver.h
+++ b/acsMotionApp/src/SPiiPlusAuxDriver.h
@@ -18,7 +18,7 @@
 #define analogInputString         "ANALOG_INPUT"
 #define analogOutputString        "ANALOG_OUTPUT"

-class SPiiPlusAuxIO : public asynPortDriver {
+class epicsShareClass SPiiPlusAuxIO : public asynPortDriver {

However, it still built fine. I don't understand this, it should screw up if epicsExport.h is in the wrong place.

@anjohnson can you explain why this is not giving an error about asynPortDriver being defined as dll_import in this module?

[anjohnson]

I have no hard evidence for this but I suspect Microsoft's linker may include some code that checks for incorrectly-decorated symbols and resolves then properly, up to so many symbols beyond which it gives up doing that (or maybe it has limited storage space for the info about the necessary corrections). I have in the past found quite a few incorrect decorations which should have failed to link like you see there but worked fine on MS builds (but did fail on MinGW builds which use the GNU linker). That's the only way I've been able to explain these kinds of issues.

[kmpeters]

I'll create a branch to test the suggested fixes.

[kmpeters]

I can't test the windows builds right now; my computer failed to reboot after updates were installed.

[kmpeters]

I'm not able to recreate the build problem with Visual Studio 2015. I'll change #34 so it isn't a draft so the github actions builds can run.