Issues with compiling c++ generated file for windows via visual studio

[Arnavpmr]

Hi, I was wondering if it was possible to statically compile a souffle generated c++ file to run natively on windows.
There were no issues at all when I compiled it with g++ on linux. I'm sure I'm using the wrong versions when attempting it on windows since there are just so many outputted errors. For my usecase, I want it to be able to run natively on windows without any emulation like WSL, Cygwin, etc. Is there any documented process for compiling a generated c++ file to run natively on windows instead of building the souffle interpreter?

[quentin]

Hi, our CI tests on Windows use MSVC.
If you built souffle yourself, you can take a look at compile options in the generated file souffle-compile.py.

Otherwise you can look for MSVC-specific options in our CMakeLists.txt files:

souffle/src/CMakeLists.txt

Lines 387 to 425 in 437f280

	if (MSVC)
	target_compile_options(libsouffle PUBLIC /Zc:__cplusplus)
	target_compile_options(compiled PUBLIC /Zc:__cplusplus)
	target_compile_options(souffleprof PUBLIC /Zc:__cplusplus)
	target_compile_options(libsouffle PUBLIC /bigobj)
	target_compile_options(compiled PUBLIC /bigobj)
	target_compile_options(libsouffle PUBLIC /wd5105)
	target_compile_options(compiled PUBLIC /wd5105)
	target_compile_options(libsouffle PUBLIC /wd6326)
	target_compile_options(compiled PUBLIC /wd6326)
	target_compile_options(libsouffle PUBLIC /wd26110)
	target_compile_options(libsouffle PUBLIC /wd4065 /wd4200)
	# to prevent old versions of Flex from redeclaring int types
	target_compile_definitions(libsouffle PRIVATE __STDC_LIMIT_MACROS)
	target_compile_definitions(libsouffle PUBLIC _CRT_SECURE_NO_WARNINGS)
	if (NOT (MSVC_VERSION LESS 1910))
	target_compile_options(libsouffle PUBLIC /permissive-)
	target_compile_options(compiled PUBLIC /permissive-)
	endif()
	target_compile_options(libsouffle PUBLIC /Zc:preprocessor)
	target_compile_options(compiled PUBLIC /Zc:preprocessor)
	target_compile_options(souffleprof PUBLIC /Zc:preprocessor)
	target_compile_options(libsouffle PUBLIC /EHsc)
	target_compile_options(compiled PUBLIC /EHsc)
	target_compile_options(souffleprof PUBLIC /EHsc)
	target_compile_definitions(libsouffle PUBLIC USE_CUSTOM_GETOPTLONG)
	target_compile_definitions(compiled PUBLIC USE_CUSTOM_GETOPTLONG)
	target_compile_definitions(souffleprof PUBLIC USE_CUSTOM_GETOPTLONG)
	endif (MSVC)

I guess /Zc:preprocessor and /Zc:__cplusplus will be helpful.

[Arnavpmr]

I really appreciate your quick response!
I tried running souffle-compile.py and it was able to compile it into an executable!
A slight issue is that the executable is dynamically linked. When I tried testing it on a clean windows virtual machine (one without souffle), I got 2 error message popups that said sqlite3.dll and zlib1.dll are missing. I am very confused at this error because the souffle-compile.py config shows that these 2 libraries are supposed to be static in link_options.

#!/usr/bin/env python3
JSON_DATA_TEXT = """{
  "compiler": "C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe",
  "compiler_id": "MSVC",
  "compiler_version": "19.29.30154.0",
  "msvc_version": "1929",
  "includes": "-ID:/a/souffle/souffle/src/include -ID:/a/souffle/souffle/build/vcpkg_installed/x64-windows/include",
  "std_flag": "-std:c++17",
  "cxx_flags": "/bigobj -openmp",
  "cxx_link_flags": "",
  "release_cxx_flags": "/O2 /Ob2 /DNDEBUG /MD",
  "debug_cxx_flags": "/Zi /Ob0 /Od /RTC1 /MDd",
  "definitions": "-DRAM_DOMAIN_SIZE=64 -DUSE_LIBZ -DUSE_SQLITE -DUSE_CUSTOM_GETOPTLONG",
  "compile_options": " /Zc:__cplusplus /bigobj /wd5105 /wd6326 /permissive- /Zc:preprocessor /EHsc",
  "link_options": "/link  D:/a/souffle/souffle/build/vcpkg_installed/x64-windows/lib/sqlite3.lib D:/a/souffle/souffle/build/vcpkg_installed/x64-windows/lib/zlib.lib ",
  "rpaths": "D:/a/souffle/souffle/build/vcpkg_installed/x64-windows/lib;D:/a/souffle/souffle/build/vcpkg_installed/x64-windows/lib",
  "outname_fmt": "/Fe:{}",
  "libdir_fmt": "/libpath:{}",
  "libname_fmt": "{}.lib",
  "rpath_fmt": "",
  "path_delimiter": ";",
  "exe_extension": ".exe",
  "source_include_dir": "D:/a/souffle/souffle/src/include",
  "jni_includes": ";"
}"""

I don't know if these libraries were missing so the linker defaulted to using dll's assuming that's its behavior. Is the source_include_dir statically linked by default?