Support for MSVC compilers #46
Conversation
…stigate-migrating-to-meson
|
Currently, the Linux tests have the following error:
I have no idea why the current branch does not have this issue and my branch does, even after spending the better half of today on this issue. The build logs are also practically identical... |
|
All tests now pass. It seams that using multi-threaded testing procedures were the cause of these errors. |
ErichZimmer
changed the title
Update GH actions version
Some restructuring to make the flow of the READEME file better.
The dependencies section was not clear enough on compilers and python. It made it look like meson were installing python and c++ compilers as dependencies.
- Revise MinGW compiler statement on Windows build environment - Add Intec oneAPI to known working Windows c/c++ compilers - Revise statement on using Windows build environment in Unix-like systems
- Spelling Mistakes
Preface
By default, MSVC compilers cannot be used to compile shared/dynamic libraries since symbols are not exported by default. However, manually exporting symbols if a MSVC compiler is detected is relatively straight forward and is covered in this pull request. To support MSVC, necessary classes and members of classes are exported using preprocessor directives and conforming to C4251. (e.g., no dll interface warnings). As such, openpivcore compiles using VS 2019 and VS 2022 without the use of SIMD (pocketfft uses GNU vector extensions which has no MSVC port).
New:
openpiv/core/dllexports.hdefines export macroChanges:
openpiv/core/rect.hnow exports necessary public class membersopenpiv/loaders/image_loader.hnow exports necessary public class membersopenpiv/loaders/pnm_image_loader.hnow exports necessary public class membersopenpiv/loaders/tiff_image_loader.hnow exports necessary public class membersREADME.mdSome minor enhancementsWork in Progress: