Closed Overhatted closed 3 days ago
Does it not work with LM_EXPORT defined in static builds? My idea was either export or import, I'm not sure about having neither as an option
Does it not work with LM_EXPORT defined in static builds? My idea was either export or import, I'm not sure about having neither as an option
afaik if defined & during MSVC windows build it will let you build LIB. if not defined it should let you build DLL on windows OS by MSVC toolchain.
It does work with __declspec(dllexport) when building static libraries. Not even sure what the consequences are or if the methods get exported if the .lib is linked into a .dll. I think the compiler creates some trampoline methods when dllexport is specified though. Either way, all the projects I've used, used this approach of not adding anything when building a static library. For example:
Does it not work with LM_EXPORT defined in static builds?
Yes it works, this one is optimization targeted for Windows OS I guess. Dunno too problematic to push it without testing existing CI workflows that build libmem itself & Rust/Python3 bindings over different OS-es as well. Maybe bindings would need rework, but in case of OS-es it should be fine.
My idea was either export or import, I'm not sure about having neither as an option
Do you tend to keep only one define for this situation such as LM_EXPORT or LM_STATIC (This one keeps stuff relying over EXPORT defininition https://github.com/libsdl-org/SDL/blob/d1af211010adb1030ce04860437fd5a580cf8eed/include/begin_code.h#L60)?
Overall it looks good now.
This PR seems to be approved. Can someone merge it? I don't think I have permissions.
I'm afraid this might break the automated build system... Only one way to find out 👀
Works, thanks!
Simple PR to avoid adding "__declspec(dllexport)" to function declarations when creating a static library.