[MS VS .NET] Compiling the lib - One single .lib or not?

[cr_itm]

Hello,

I'm new to wxWidgets and have just downloaded the source. I compiled the lib with Visual Studio .NET the way it was described on a webpage (was it wxWiki?) -> I builded the workspace in the folder "wxWidgets-2.6.0/build/msw/wx.dsw". After compiling it, there were a lot of single .lib files in the "wxWidgets-2.6.0/lib/vc_lib" directory.

Now I tried to setup a new project with these instructions:
http://wiki.wxwidgets.org/wiki.pl?MSVC_.NET_Setup_Guide

When I try to compile my app, the linker says, there is no "wxmsw.lib" file. It not that I set up wrong path to the includes or libs, the file "wxmsw.lib" is just not there.

If I use "wxWindows.dsw" in the "src" folder and build the lib, than the file "wxmsw.lib" is there.

May someone explain the difference between building the lib(s) with the "wxWidgets-2.6.0/build/msw/wx.dsw" and the "wxWindows.dsw" in the "src" folder and above all, which one I should use?


Thanks in advance for you help

[leio]

If I use "wxWindows.dsw" in the "src" folder and build the lib, than the file "wxmsw.lib" is there.

May someone explain the difference between building the lib(s) with the "wxWidgets-2.6.0/build/msw/wx.dsw" and the "wxWindows.dsw" in the "src" folder and above all, which one I should use?

Definately don't use the one in the "src" folder. I have no idea why it was kept around, but all say it's broken, old, and shouldn't be used. The preferred way of doing the libraries is the multiple library way. But unfortunately some projects don't use that, and expect a monolithic library. Some of them might also work only with wxWidgets-2.4.2 unfortunately. These are the projects that don't get attention from its developers.
In the "batch build" (so named in VC6, perhaps diff name in .NET) can't you tick a monolithic build of wxMSW, unicode or non-unicode?

[cr_itm]

The preferred way of doing the libraries is the multiple library way. But unfortunately some projects don't use that, and expect a monolithic library.

Thanks for your help. Now I don't use the "src"-files anymore to build the lib. But if you say, that the preferred way of building the libraries is to build several single lib's - why does my project ask for a single wxmsw.lib file? Furthermore, when I try to build any of the sample-projects, they always need one single lib file.

In the "batch build" (so named in VC6, perhaps diff name in .NET) can't you tick a monolithic build of wxMSW, unicode or non-unicode?

There are these sorts of builds I can choose from (when I understood it right):

Debug
Release
DLL Debug
DLL Release
Universal Debug
Universal Release

Non of them give me a single lib file, they all create several lib files.


I must admit, I don't understand the whole architecture of wxWidgets. I mean, after I compile the libs, why aren't they in the lib folder (they are in the "lib/vc_lib/" folder)? How can I create one single lib - or more important, how can I get the samples work with those several small lib files?

(I also had problems creating my own project without the single big lib file, but thats another issue, I first want to understand this thing with the libs...)


Thanks a lot for your help - you see, I'm a little bit confused here

[eco]

I must admit, I don't understand the whole architecture of wxWidgets. I mean, after I compile the libs, why aren't they in the lib folder (they are in the "lib/vc_lib/" folder)? How can I create one single lib - or more important, how can I get the samples work with those several small lib files?

(I also had problems creating my own project without the single big lib file, but thats another issue, I first want to understand this thing with the libs...)

The reason for the individual subfolders in lib is because wxWidgets can be built a number of different ways so placing them in separate folders prevents different builds for conflicting with one another.

The samples should all just work. Open up their workspace and do a Build Solution.

If I remember correctly, wxmsw.lib is from the 2.4.x series. 2.5.x+ (including 2.6.0) all break the library up into several smaller libraries (then you can pick and choose what you want to link to more easily).

Here is what a Debug build of one of my application links to for wxWidgets 2.6.0:

wxmsw26d_adv.lib wxmsw26d_html.lib wxmsw26d_core.lib wxmsw26d_qa.lib wxbase26d.lib wxbase26d_xml.lib wxtiffd.lib wxjpegd.lib wxpngd.lib wxzlibd.lib wxregexd.lib wxexpatd.lib

You may not need all of those libraries. For a release build, link to the same except removing the trailing "d" in each of the libraries.

The best way I've found to setup wxWidgets with your own projects is to create an environment variable called something like WXDIR which contains the path to wxWidgets (e.g. "C:\wxWidgets-2.6.0"). Then, in your MSVC Tools | Options window, add to Projects > VC++ Directories in the Library files section "$(WXDIR)\lib\vc_lib" and "$(WXDIR)\include" to Include Files section. Then, in your project settings in the C/C++ > General section add "$(WXDIR)\lib\vc_lib\mswd" to your Additional Include Directories field for debug builds and "$(WXDIR)\lib\vc_lib\msw"; for release builds (this is to specify where the setup.h for the particular library you are linking to is at). Then, when upgrading or switching to a new version of wxWidgets, you only have to change that environment variable and everything just works and for someone else to use your project, all they have to do is add a WXDIR environment variable which makes this method very useful for multiuser projects. Also, it minimizes the setup needed to start a new project since all you need to do now is add those extra include directores and the library names.

[Jorg]

I had to figure this out a while ago and this is what I do:

Include dirs;
$(WXWIN)/include/
$(WXWIN)/lib/vc_lib/mswd (and without the d for release, altough both setup.h files are similar)

Additional linker directories:
$(WXWIN)/lib/vc_lib/

Linker libs:
wxmsw26d_adv.lib wxmsw26d_html.lib wxmsw26d_core.lib wxmsw26d_qa.lib wxbase26d.lib wxbase26d_xml.lib wxtiffd.lib wxjpegd.lib wxpngd.lib wxzlibd.lib wxregexd.lib wxexpatd.lib

Preprocessor macros:
__WXMSW__ WXDEBUG=1 __WXDEBUG__ (latter for debug only)

I have recently developed a new CMake script (FindWxWin.cmake) and had to check out how it was done by bakefile. These flags are all you need.

Ofcourse match your threading model to MultiThreaded Debug DLL and MultiThreaded DLL to avoid linker errors.

For UNICODE, add a u to the lib like
wxmsw26d_advu.lib
wxmsw26d_advud.lib (with debug)

wxUniversal is also possible, but I don't know if it works, the last I heard they said it was broken ..

- Jorgen

[Avi]

Well, I already opened a post about monolithic builds a while ago, so you might wanna check it out for more information regarding the issue...

[cr_itm]

Thanks a lot for all your help, now all runs smoothly

I followed your idea and created a inv. variable named WXPATH, it's a good way to setup VS.

However, I have some questions left:

- I read that I must use the preprocessor statements "WINVER=0x0400;wxUSE_GUI=1" - are these relics from older versions of wx? Because without them all runs well.

- I don't quite understand, why I must use "MultiThreaded Debug DLL", especially the "DLL", where is the DLL?

- With what kind of lib does someone usually work? The debug version or the release version of the libs? I mean, do I need the debug version to debug my code when I don't want to debug wxWidgets itself?


Well, thanks again for your great help.

[Avi]

- I read that I must use the preprocessor statements "WINVER=0x0400;wxUSE_GUI=1" - are these relics from older versions of wx? Because without them all runs well.

- I don't quite understand, why I must use "MultiThreaded Debug DLL", especially the "DLL", where is the DLL?

I've been wondering about these too! Could someone comment?

- With what kind of lib does someone usually work? The debug version or the release version of the libs? I mean, do I need the debug version to debug my code when I don't want to debug wxWidgets itself?

Well, sometimes wxWidgets itself has problems too. I personally link my debug-app-build to wx-debug-build and my release-app-build to a wx-release-build... It allows me to fully debug my code, as I can see what the wxWidgets classes receive from it...