It would be great to add CMake solution

[Deamhan]

By using CMake we can create more flexible and portable solution (support more IDEs, automatic find wxWidgets location and more).

[utelle]

Of course, I'm not against adding CMake support. However, I have to admit that I don't have much experience with CMake. So, assistance from an experienced CMake user would be welcome.

The problem with CMake is that users need to install CMake to generate build files, and that it is not possible to generate them in advance. That is, adding CMake support will be fine, but most likely it will not replace the preconfigured build files currently coming with wxSQLite3.

In the past (several years ago) it was not possible to generate for example Visual C++ solutions which supported both, release and debug, builds at the same time. Similarly, one had to generate separate build files for different architectures. This made using CMake generated solutions quite cumbersome. Hopefully this has changed for recent CMake versions.

[Deamhan]

OK, glad to hear it. I have some experience with it and I will try to create CMakeLists. At least now I have no issues with different build configurations on VS or QtCreator.

[utelle]

If you provide an initial version of CMakeLists, I will give them a try. And of course those CMakeLists can be improved in the future in case they have deficiencies.

[utelle]

In the CMakeLists.txt file I see long lists of explicit compiler options. IMHO this could cause subtle issues if the wxWidgets library itself was compiled with a different set of compiler options.

From my point of view it is necessary to take measures to make sure that a compatible set of compiler options is used.

[Deamhan]

Are you are talking about

add_compile_options(
/Zi # pdb
/W4 # warning level 4
/EHsc # exceptions: sync
/J # use unsigned char
/Gd # use cdecl
# treat warnings as errors
/we4715 # not all control paths return a value
/we4828 # disallow invalid characters
# prinf-like functions: format mismatch
/we4473 # : not enough arguments passed for format string
/we4474 # : too many arguments passed for format string
/we4475 # : length modifier cannot be used with type field character in format specifier
/we4476 # : unknown type field character in format specifier
/we4477 # : format string requires an argument of type , but variadic argument has type
/we4478 # : positional and non-positional placeholders cannot be mixed in the same format string
/we4775 # nonstandard extension used in format string of function
/we4776 # % is not allowed in the format string of function
/we4777 # : format string requires an argument of type , but variadic argument has type
/we4778 # : unterminated format string
# macro arg mismatch
/we4002 # too many actual parameters for macro 'identifier'
/we4003 # not enough actual parameters for macro 'identifier'
/Zc:threadSafeInit- # https://connect.microsoft.com/VisualStudio/feedback/details/1789709/visual-c-2015-runtime-broken-on-windows-server-2003-c-11-magic-statics
/MP # multiprocessor compilation
/utf-8 # utf-8 source & exec
/GF) # eliminate duplicate strings

?
I agree about /EHsc option - this may conflict with wxWidgets that was built with /EHa (https://trac.wxwidgets.org/ticket/18436) - I will add special options for it. Other options have no impact on linking process, but I will add special option for "pedantic" flags and so on. Thank you for review!

[Deamhan]

Done: #67 .

[utelle]

Are you are talking about ...

Yes. Of course, most options (like handling of warnings) do not affect the resulting binaries, but some do (as you confirmed). Thanks for addressing this.

[Deamhan]

It would be great to add some CMake build tests to prevent it damage. What do you think about that?

[utelle]

Sure. It would make sense to add tests to verify that the CMake build functions properly.

[utelle]

Regarding tests for verifying CMake builds most likely it would be best to add CI under Windows for example based on AppVeyor. However, I will have to investigate AppVeyor first, because I never have used it before.

I assume that the current CMake support works for you. From other sides I didn't get any feedback. Therefore I intend to make a wxSQLite3 release in the near future.

[utelle]

Today I added AppVeyor CI to wxSQLite3. After a few attempts I got a wxSQLite3 build using VS2017 to work.

On the AppVeyor VMs CMake version 3.15.0 is available. By adjusting the AppVeyor scripts it should be possible to add a CMake test case. Would you be willing to set up such a CMake test case? (Looking at the AppVeyor scripts wxWidgets itself uses might help in doing so.)

[aisnote]

any readme on how to use CMake to build the wxSqlite3? I have few experience on CMake

[utelle]

Well, as I mentioned already in a previous post, I'm not a CMake expert either. Of course, I'm not against having CMake build support for wxSQLite3. However, I would prefer a generic approach which is really portable to other platforms. At the moment the CMake build file is cluttered with Windows and compiler specific elements. Theoretically, building with CMake should work by simply invoking CMake in the build directory. I doubt that adding the previous sentence to the documentation is worth the effort.