Compilation with msv142 (visual studio 2019)

[blaurent49]

Hello, I know that there is no build files provided for visual studio 2019. However, is there another way to compile in this environnement ? (using a makefile in visual studio 2019 command prompt for example). Best regards, Benoît

[utelle]

Usually opening the build files for VS2017 from Visual Studio 2019 should work, too.

However, I recently adjusted the property file wx_setup.props in the build subdirectory to allow running AppVeyor CI without any modifications.

This modification triggers the use of specific library directories for different compiler versions (as it is used by the pre-built wxWidgets libraries). This adds the toolkit version (141 for VS 2015, 142 for VS 2019) to the library path name.

There is a problem with the wxWidgets 3.1.2 release, because it doesn't support VS 2019 in this mode yet. The file include/msvc/wx/setup.h has been updated (lines 68 to 71) in the wxWidgets GitHub repository, but the released version selects the wrong toolkit version (the one belonging to VS 2015).

Besides that, I'm currently preparing a new release of wxPdfDocument that will include build files for VS2019, too. The release date is not yet fixed, but most likely it will be within about a week.

[blaurent49]

Thank you first for your quick answer.

Usually opening the build files for VS2017 from Visual Studio 2019 should work, too. Visual Studio 2019 indeed opens the vx2017 solution file. However, I encounter many compilation errors, in the setup.h file : the _MSC_VER is unknown.

I shall have a try with AppVeyor but I must admit that I have never used it before.

I use wxWidgets 3.0.4. Is there the same problem ?

If I fail to compile, I will wait for the new release.

Thank you again for your help.

[utelle]

Usually opening the build files for VS2017 from Visual Studio 2019 should work, too. Visual Studio 2019 indeed opens the vx2017 solution file. However, I encounter many compilation errors, in the setup.h file : the _MSC_VER is unknown.

Now, this is really strange, because _MSC_VER is a preprocessor symbol that is defined by Visual Studio itself. Please show the exact error messages you get. Maybe this helps to track down the cause of the problem.

I shall have a try with AppVeyor but I must admit that I have never used it before.

AppVeyor is used only for CI (Continuous Integration) under Windows. And a precompiled version of wxWidgets is used for that purpose. Therefore, I had to adjust the property file wx_setup.props.

If you use a default wxWidgets build you can edit wx_setups.props so that the properties wxCompilerPrefix and wxMsvcVersionAuto are defined as follows:

<wxCompilerPrefix>vc</wxCompilerPrefix>
<wxMsvcVersionAuto></wxMsvcVersionAuto>

I use wxWidgets 3.0.4. Is there the same problem ?

In principle, yes. However, if you adjust wx_setups.props as said above, you should not experience problems.

[blaurent49]

Now, this is really strange, because _MSC_VER is a preprocessor symbol that is defined by Visual Studio itself. Please show the exact error messages you get. Maybe this helps to track down the cause of the problem. I cloned the wxpdfdoc on my computer (this morning, I used the zip file).

I obtained the following error: It is seems to me quite "natural" since _MSC_VER == 1922.

[utelle]

Ok, this is the problem I mentioned. The official wxWidgets releases up to version 3.1.2 do not support Visual C++ 2019 yet. However, the relevant file setup.h is already updated in the wxWidgets master. One way, to solve the problem, would be to exchange this file in your wxWidgets installation.

If you adjust the file wx_setup.props in directory build of wxPdfDocument as described in my previous post, the error message should go away, too.

[vadz]

I'd just like to add that I build wxPdfDoc with MSVS 2019 and the current wx master (soon to be released as 3.1.3) without any problems.

[blaurent49]

If you adjust the file wx_setup.props in directory build of wxPdfDocument as described in my previous post, the error message should go away, too.

I used this second solution and it compiles just fine now. Thank you very much for your help.

[utelle]

@vadz The compile problem is partially a result of my adjustments to the property file wx_setup.props. Since I use a precompiled version of wxWidgets for the AppVeyor CI, and the precompiled wxWidgets version uses a VC++ specific compiler version prefix, I had to do that.

However, it seems the typical wxWidgets developer does not use specific compiler version prefixes. Thus, it is now required to adjust wx_setup.props before compiling wxPdfDocument.

Any idea, how to overcome this problem?

[utelle]

Build files for VS2019 were added in commit b19608afd1182fc243385d03c73890fe87231a2f.

However, at the moment it is still necessary to adjust wx_setup.props if the default wxWidgets compiler prefix should be used.

[vadz]

Any idea, how to overcome this problem?

Not really. This is quite annoying, but I'm not really sure how to change things here to make them better and not worse. I think we should include wx_setup.props corresponding to the build into the _Dev packages, as then you could just include it in your own .props, but we don't do this currently. Would it help if I did this before 3.1.3 release?

[utelle]

If the pre-compiled _Dev packages would include the wx_setup.props file that was used to build them, would certainly help, as it could be reused in CI. I don't think that doing so would make things worse.

The "problem" is that the typical wxWidgets user doesn't touch wx_setup.props (and doesn't create wx_local.props), but simply builds the wxWidgets libs with the build files as they are released. For a long time I did it that way myself, I have to admit. However, now that I test and use my wxWidgets components with various Visual C++ versions, I got used to like and prefer to specify wxCompilerPrefix and to make the selection of the version (in setup.h) automatic (using wxMsvcVersionAuto).

However, I fear that changing the distributed build files for Visual C++ in that way (except for the pre-compiled bundles), would make things worse, as most wxWidgets users don't use compiler prefixes. It would force them to adjust all their dependent projects' build files.

[vadz]

Just FYI: we'll try including wxwidgets.props with the compiler prefix corresponding to the MSVC version being used into the _Dev distributions of 3.1.3 (I've opened this ticket to track this task).

We'll also probably use vc14x prefix for all 14.x compiler versions (MSVS 2015, 2017 and 2019), as they're all ABI-compatible with each other.

[utelle]

Just FYI: we'll try including wxwidgets.props with the compiler prefix corresponding to the MSVC version being used into the _Dev distributions of 3.1.3 (I've opened this ticket to track this task).

Definitely good news.

However, from my point of view it should also be considered to always use the toolset specific compiler prefix in the build files of the official wxWidgets distribution (instead of the generic vc compiler prefix).

We'll also probably use vc14x prefix for all 14.x compiler versions (MSVS 2015, 2017 and 2019), as they're all ABI-compatible with each other.

I really have my doubts that this will work. As far as I understood Microsoft's ABI compatibility statement, compatibility is a one-way route: you can use for example a library that was compiled with VS2015 in a project for which you use VS2017 (or VS2019). But the opposite is not true: you can't use a library that was compiled with VS2017 (or VS2019) in a project you still compile with VS2015.

The idea behind ABI compatibility is that a developer doesn't need to upgrade all libraries that his project depends on at once (or at all). However, upgrading them in the long run is recommended to take advantage of new features and optimizations.

Therefore I think that it still makes sense to have pre-built wxWidgets libraries for all of the compatible versions (VS2015, VS2017, and VS2019). Only, if you want to reduce the number of pre-built versions you could restrict this process to build just the version compiled with VS2015 as it could be used without problems in VS2017 or VS2019 based projects.

[vadz]

However, from my point of view it should also be considered to always use the toolset specific compiler prefix in the build files of the official wxWidgets distribution (instead of the generic vc compiler prefix).

This would break all the existing build/project files assuming vc prefix though and I'm just not sure we can justify this.

We'll also probably use vc14x prefix for all 14.x compiler versions (MSVS 2015, 2017 and 2019), as they're all ABI-compatible with each other.

I really have my doubts that this will work. As far as I understood Microsoft's ABI compatibility statement, compatibility is a one-way route: you can use for example a library that was compiled with VS2015 in a project for which you use VS2017 (or VS2019). But the opposite is not true: you can't use a library that was compiled with VS2017 (or VS2019) in a project you still compile with VS2015.

Actually, you can. I'm doing exactly this and using wxWidgets built with VS2019 from an application compiled with VS2017 without any problems.

Therefore I think that it still makes sense to have pre-built wxWidgets libraries for all of the compatible versions (VS2015, VS2017, and VS2019). Only, if you want to reduce the number of pre-built versions you could restrict this process to build just the version compiled with VS2015 as it could be used without problems in VS2017 or VS2019 based projects.

We will indeed build the vc14x libraries using VS2015, just to be on the safe side, but I don't see why should we waste time and space by providing VS2017 and VS2019 builds too -- the cost might be not that big, but I just don't see any advantages in doing this.

[utelle]

This would break all the existing build/project files assuming vc prefix though and I'm just not sure we can justify this.

I know. This is certainly nothing to be considered for a minor release. But maybe for a major one. 😉

Of course, I can live with whatever is decided by the wxWidgets team. For my own projects I use property files nowadays, so I can easily adjust the project build process.

Actually, you can. I'm doing exactly this and using wxWidgets built with VS2019 from an application compiled with VS2017 without any problems.

Maybe this works, because you have installed both VS versions. Have you tested to run the application on a computer where only the VS2017 runtime is installed? If I understood it correctly an application that uses binary components from both, VS2017 and VS2019, requires the VS2019 runtime. That is, most likely you have to take into account the various versions of your components to select the right runtime redistributable for your application.

However, I have to admit that I haven't tested this myself yet. So, I might be wrong.

We will indeed build the vc14x libraries using VS2015, just to be on the safe side, but I don't see why should we waste time and space by providing VS2017 and VS2019 builds too -- the cost might be not that big, but I just don't see any advantages in doing this.

Personally I would always prefer to use matching toolset versions for all components of my application if possible (as is also recommended by Microsoft). In fact, I don't have any problems with building wxWidgets myself if necessary. Therefore, if it is decided to pre-build only a single version for VS2015, VS2017, and VS2019, I'm fine with that decision.

The only remaining question in this context is, which compiler prefix will then be selected in the future in setup.h if wxMsvcVersionAuto is activated. Will it depend on the toolset (as is the case now), or will it be vc14x for VS2015 and above?

[vadz]

Actually, you can. I'm doing exactly this and using wxWidgets built with VS2019 from an application compiled with VS2017 without any problems.

Maybe this works, because you have installed both VS versions. Have you tested to run the application on a computer where only the VS2017 runtime is installed?

To be honest, no, but looking at the dependencies of the generated executables, they seem to only depend on msvcp140.dll and nothing else. I think that the newer CRT DLLs are loaded during run-time only if needed and available.

The only remaining question in this context is, which compiler prefix will then be selected in the future in setup.h if wxMsvcVersionAuto is activated. Will it depend on the toolset (as is the case now), or will it be vc14x for VS2015 and above?

It will be vc140 etc if wxMSVC_VERSION_AUTO is defined, but vc14x if the (new) wxMSVC_VERSION_ABI_COMPAT is defined.

[utelle]

To be honest, no, but looking at the dependencies of the generated executables, they seem to only depend on msvcp140.dll and nothing else. I think that the newer CRT DLLs are loaded during run-time only if needed and available.

I have to admit that I haven't studied the inner details. However, to be on the safe side it is most likely advisable to install the latest runtime that came with VS2019. Then implicitly the most recent VS2015 and VS2017 versions will be available, too.

It will be vc140 etc if wxMSVC_VERSION_AUTO is defined, but vc14x if the (new) wxMSVC_VERSION_ABI_COMPAT is defined.

Great. That way it can be defined as is appropriate for given circumstances.