Build for Visual Studio 2019

Do you have a question about makefiles, a compiler or IDE you are using and need to know how to set it up for wxWidgets or why it doesn't compile but other IDE's do ? Post your questions here.
User avatar
doublemax
Moderator
Moderator
Posts: 19114
Joined: Fri Apr 21, 2006 8:03 pm
Location: $FCE2

Re: Build for Visual Studio 2019

Post by doublemax »

Use static linking. I can only think of very few reasons for using DLLs anyway.
Use the source, Luke!
PB
Part Of The Furniture
Part Of The Furniture
Posts: 4193
Joined: Sun Jan 03, 2010 5:45 pm

Re: Build for Visual Studio 2019

Post by PB »

purplex88 wrote: Mon Jun 10, 2019 7:12 pm
This program can't start because wxbase312ud_vc_custom.dll is missing from your computer.
Rather than moving wxbase312ud_vc_custom.dll next to .exe? I can't run the project from Visual Studio.
You will still have to distribute all the DLLs to the users along the executable but for development, you can add the folder with wxWidgets DLLs to your project.

In MSVC go to project properties / Configuration Properties / Debugging and in the Environment field add the folder. E.g, for DLL Debug it would be (assuming you have system environment WXWIN set properly):

Code: Select all

PATH=$(WXWIN)\lib\vc_dll
Do the same for the Release configuration and you should be set.
purplex88
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 247
Joined: Mon Feb 24, 2014 3:14 pm

Re: Build for Visual Studio 2019

Post by purplex88 »

Thanks, that environment path technique worked. I won't distribute the program with DLLs,right.

I thought dynamic linking will take less amount of compile and build time? So, I can build, run and test quickly?

My another little doubt: is WIN32 a right macro? Shouldn't it be _WIN32? There's no WIN32 macro in MSDN documentation. Is it special to wxWidgets?
PB
Part Of The Furniture
Part Of The Furniture
Posts: 4193
Joined: Sun Jan 03, 2010 5:45 pm

Re: Build for Visual Studio 2019

Post by PB »

purplex88 wrote: Tue Jun 11, 2019 6:13 am thought dynamic linking will take less amount of compile and build time? So, I can build, run and test quickly?
I never timed it but I think time taken by statically linking a library such as wxWidgets would be negligible.
purplex88 wrote: Tue Jun 11, 2019 6:13 am My another little doubt: is WIN32 a right macro? Shouldn't it be _WIN32? There's no WIN32 macro in MSDN documentation. Is it special to wxWidgets?
I think _WIN32 is defined by the MSVC itself when targeting the platform, similarly to _LIB and _DEBUG when using the static debug version of the CRT, see here.

I believe that for the debug configuration, the only required MSW-specific project defines are __WXMSW__, _UNICODE, and UNICODE. I myself add also NDEBUG to the release one...
purplex88
Filthy Rich wx Solver
Filthy Rich wx Solver
Posts: 247
Joined: Mon Feb 24, 2014 3:14 pm

Re: Build for Visual Studio 2019

Post by purplex88 »

Note that I mean WIN32 not _WIN32. What is WIN32 for? I found this in minimal build :P
PB
Part Of The Furniture
Part Of The Furniture
Posts: 4193
Joined: Sun Jan 03, 2010 5:45 pm

Re: Build for Visual Studio 2019

Post by PB »

As I said, I believe WIN32 is not needed. wxWidgets defines this macro itself in platform.h:

Code: Select all

#if defined(_WIN32) || defined(__WIN32__) || defined(__WXMSW__)
#    ifndef __WINDOWS__
#        define __WINDOWS__
#    endif /* !__WINDOWS__ */
#endif /* Any standard symbol indicating Windows */ 

#if defined(__WINDOWS__)
    /* Select wxMSW under Windows if no other port is specified. */
#   if !defined(__WXMSW__) && !defined(__WXMOTIF__) && !defined(__WXGTK__) && !defined(__WXX11__) && !defined(__WXQT__)
#       define __WXMSW__
#   endif

#   ifndef _WIN32
#        define _WIN32
#   endif

#   ifndef WIN32
#        define WIN32
#   endif
 
Post Reply