Modified & Improved wxWidgets Project Wizard

[Biplab]

Another update to the wizard.

Changes:

• Supports Pre-compiled headers for BCC 5.5.1 and MSVC 8.
• Wizard CPP files are modified to support PCH.
• "Use the debugging libraries" option have been disabled in Windows part. This option is no longer necessary (See screenshot below).
• DECLARE_EVENT_TABLE(); in main.h file has been changed to DECLARE_EVENT_TABLE() This is necessary to avoid error while compiling with BCC.
• msvcrt.lib is now added as /NODEFAULTLIB in Debug target of MSVC 8 to avoid warning messages in some cases.

Known Issues:

• PCH support does not work with MSVC 6 or 7.1
• wx_pch.h file is included in the CPP files and also force included in case of GCC and MSVC. I have kept the force include option as some devs want this to remain. To support Borland, wx_pch.h have been added to CPP files itself. In future this option will be modifed as per CB devs and other users decision.

Please post your valuable feedbacks. 

P.S. - I was trying to include support for MSVC 7.1 also. But my VC 7.1 installation is horribly broken.  :evil:  It wasted a lot of time.

[attachment deleted by admin]

[MortenMacFly]

• Wizard CPP files are modified to support PCH.

Just my personal thoughts on that (nice!!!) work:
I wonder if it would make sense to separate the PCH feature into an own wizard. PCH isn't something possible for wx only (obviously). Do you think from your experience it would be possible to extract a "PCH enabling wizard" out of this one that can be applied to *any* project?
With regards, Morten.

[Biplab]

• Wizard CPP files are modified to support PCH.

Just my personal thoughts on that (nice!!!) work:
I wonder if it would make sense to separate the PCH feature into an own wizard. PCH isn't something possible for wx only (obviously). Do you think from your experience it would be possible to extract a "PCH enabling wizard" out of this one that can be applied to *any* project?
With regards, Morten.

Thanks for your comments. 

A "PCH enabling wizard" is possible and I think that's a good idea, too. First I'm giving a rough sketch then I'll post my opinion.

My rough idea--

Page in Wizard  ---------------------
[ ] Option 1
[ ] Option 2
[ ] Option 3
..
[ ] Select to enable PCH support
------------------------------------

Now the wizard shows PCH page,

PCH Settings -----------------------

Please Remember that PCH works well only when you have a large
number of static headers to include and your project CPP files have
consistent header declaration.

Improper use may increase Build time!!

[ ] Create PCH through (*.h / *.cpp) file
Browse        [..................................]

PCH Handling
( ) Create & Use (Compiler Dependent)
( ) Use only (First C::B will create and then, will compile other files in Use only mode)
--------------------------------------

I would like to add it as a function in SDK so that the wizard can be called easily from any wizard.

If the Project involves huge amount of static headers, PCH would be beneficial. Otherwise not. Also the project/subproject cpp files should be consistent, otherwise regeneration of PCH file will kill the benefit.

But I feel the option may be misused by some users even for smaller and simpler projects. That would make them vent their anger on Code::Blocks itself. That's why I've put a warning message.

 

[Biplab]

A minor update to the wizard. This version has some fixes and improvements.

Changes in rev 3.3:

• Mssing preprocessor definition, USE_PCH, in project file of BCC has been fixed.
• Preprocessor definition in BCC for Unicode app has been changed to UNICODE from wxUSE_UNICODE as BCC doesn't likes it.
• Now option to select Advanced UI Library will NOT be available if wxWidgets 2.6.x is used

BCC produces a lot of errors if you are using wxUSE_UNICODE preprocessor definition. It fails as in some part of several wxWidgets headers #if <expr> has been used in place of #if defined(<expr>)

Manually editing them to #if defined clears the errors, but there are too many to modify.

Another useful info, BCC will fail to compile wxWidgets 2.8.0 in Unicode mode. To solve this, apply the patch to wx/filefn.h

http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/include/wx/filefn.h.diff?r1=1.157&r2=1.158&diff_format=u

Latest revision is attached with this post. Please login to download.

[attachment deleted by admin]

[rjmyst3]

I think wxUSE_UNICODE needs to be defined to a number
#define wxUSE_UNICODE 1
not just defined. That probably explains why BCC was upset.

[Biplab]

I think wxUSE_UNICODE needs to be defined to a number
#define wxUSE_UNICODE 1
not just defined. That probably explains why BCC was upset.

For the other two compilers, GCC and MSVC, setting flag -DwxUSE_UNICODE or /DwxUSE_UNICODE does the job. With BCC I faced the problem. I changed it to -DwxUSE_UNICODE=1 but the problem remained. Then I've decided to change it to -DUNICODE and it worked.

Will look into it again. 

[Biplab]

I think wxUSE_UNICODE needs to be defined to a number
#define wxUSE_UNICODE 1
not just defined. That probably explains why BCC was upset.

For the other two compilers, GCC and MSVC, setting flag -DwxUSE_UNICODE or /DwxUSE_UNICODE does the job. With BCC I faced the problem. I changed it to -DwxUSE_UNICODE=1 but the problem remained. Then I've decided to change it to -DUNICODE and it worked.

Will look into it again. 

Setting -DwxUSE_UNICODE OR -DwxUSE_UNICODE=1 compiler options does not solve the problem for BCC. Though adding #define wxUSE_UNICODE 1 to header files should solve the problem. The best solution I found for BCC is to add -DUNICODE to compiler option. wxWidgets then internally sets wxUSE_UNICODE to 1 for Unicode App and 0 for ANSI app internally. 

[three_minute_hero]

Hi Everyone,

I write you here just to inform you about a little problem (I don't know if I can call it "bug", but I've been quite annoyed by that) in the wizard.
It seems that the generation of the linker libraries list produce a wrong ordered list (i.e. "libwxmsw28u_richtext.a" is putted after "libwxmsw28u_core.a", which gives rise to compilation's problems).

...and a big big sorry for my awful english language!

[Biplab]

Hi Everyone,

I write you here just to inform you about a little problem (I don't know if I can call it "bug", but I've been quite annoyed by that) in the wizard.
It seems that the generation of the linker libraries list produce a wrong ordered list (i.e. "libwxmsw28u_richtext.a" is putted after "libwxmsw28u_core.a", which gives rise to compilation's problems).

...and a big big sorry for my awful english language!

Thanks for posting that bug. I'll fix it soon. 

[RJP Computing]

I am testing out the wizard with VC 8.0 here are my problems/bugs. I am using wxPack.

When not using dlls and as a monolithic lib and using pch I get this error.

-------------- Build: Debug in vc8Test ---------------
Compiling: main.cpp
Compiling: app.cpp
main.cpp
app.cpp
c1xx : fatal error C1083: Cannot open compiler intermediate file: 'obj\Debug\vc8Test.pch': No such file or directory
Process terminated with status 2 (0 minutes, 0 seconds)
0 errors, 0 warnings
 
c1xx : fatal error C1083: Cannot open compiler intermediate file: 'obj\Debug\vc8Test.pch': No such file or directory
Process terminated with status 2 (0 minutes, 0 seconds)
0 errors, 0 warnings

When I try the same as before only un-check the use pch I get an error because you are including "wx_pch.h" at the top of main.cpp and app.cpp. If you comment the 2 occurances out and add "/Zc:wchar_t-" to the compiler options it works.

NOTE: Code::Blocks developers please fix the 'wchar_t is the native type, not a typedef' option to when unchecked it should be passing  "/Zc:wchar_t-" to the compiler and when you check the setting it should send "/Zc:wchar_t". Notice the "-" at the end. Right now when you check this it sends "/Zc:wchar_t" to the compiler and this is already the default, so it makes it impossible to actually change the setting through the checkbox. I hope this makes sense.

[RJP Computing]

Here are my problems with the wizard when compiling VC7.1 toolkit. I choose the monolithic Unicode library as the options.

• It is missing 'Rpcrt4.lib' from the library list.
• The run-time needs to be selected. For Debug it should be 'Mulit-threaded Debug Runtime Library' and for Release it should be 'Mulit-threaded Runtime Library'. This will also make it so that you manually don't need to add the msvcrt[d].lib in the vc8.0 setup.
• I had to add /NODEFAULTLIB:libcmtd.lib to the linker other options. (I think this might be fixed with building the libraries including the static runtime)
• I found out that I built the monolithic libraries without using the static run-time library which I will have to fix and repost wxPack. This will make the above work as expected. When using a static library there should be no reason to include a dll of the runtime. That defeats the purpose in my opinion.

More details to come after I fix the builds of the compiled wxWidgets.

[Biplab]

If you add wx_pch.h file in NOPCH mode, it has no effect on PCH generation. It includes wx/wxprec.h file only.

Here are my problems with the wizard when compiling VC7.1 toolkit. I choose the monolithic Unicode library as the options.

• It is missing 'Rpcrt4.lib' from the library list.
• The run-time needs to be selected. For Debug it should be 'Mulit-threaded Debug Runtime Library' and for Release it should be 'Mulit-threaded Runtime Library'. This will also make it so that you manually don't need to add the msvcrt[d].lib in the vc8.0 setup.
• I had to add /NODEFAULTLIB:libcmtd.lib to the linker other options. (I think this might be fixed with building the libraries including the static runtime)
• I found out that I built the monolithic libraries without using the static run-time library which I will have to fix and repost wxPack. This will make the above work as expected. When using a static library there should be no reason to include a dll of the runtime. That defeats the purpose in my opinion.

More details to come after I fix the builds of the compiled wxWidgets.

I'm assuming you are compiling an app with MSVC7.1 generated by new wizard.

Problem 1-3 will come as nothing has been added for MSVC 7.1 or 6. So you are getting those errors. I had deliberately skipped adding any compiler options to MSVC 7.1 (some are very similar to MSVC 8 ) as I couldn't test it.

wx Dev team does not suggest us to use static library for MSVC in some cases. I'm quoting the following line from src/common/string.cpp file.

Code

#if defined(__VISUALC__) && defined(_MT) && !defined(_DLL)
#  pragma message (__FILE__ ": building with Multithreaded non DLL runtime has a performance impact on wxString!")

This warning was one of the reason I took a longer route of embedding manifest file for MSVC 8 to exe file after the build is finished. And I think it would be better if you continue building wxPack with dynamic runtime lib. 

[RJP Computing]

If you add wx_pch.h file in NOPCH mode, it has no effect on PCH generation. It includes wx/wxprec.h file only.

That would be fine but you are not creating the wx_pch.h file at all. It is missing.

...
I'm assuming you are compiling an app with MSVC7.1 generated by new wizard.

Yes I am.

Problem 1-3 will come as nothing has been added for MSVC 7.1 or 6. So you are getting those errors. I had deliberately skipped adding any compiler options to MSVC 7.1 (some are very similar to MSVC 8 ) as I couldn't test it.

OK, well that explains why it doesn't work very well.

wx Dev team does not suggest us to use static library for MSVC in some cases. I'm quoting the following line from src/common/string.cpp file.

Code

#if defined(__VISUALC__) && defined(_MT) && !defined(_DLL)
#  pragma message (__FILE__ ": building with Multithreaded non DLL runtime has a performance impact on wxString!")

This warning was one of the reason I took a longer route of embedding manifest file for MSVC 8 to exe file after the build is finished. And I think it would be better if you continue building wxPack with dynamic runtime lib. 

I have done some reading and a bit of testing and have determined that the impact for most uses is minimal. In my opinion you should be able to use the statically linked library with no other files to distribute. (Yes I know the Windows is coming with them more and more) and if you would be willing to use the runtime dll you will be willing to use wxWidgets as a dll as well. So I think this is the best compromise between speed and extra files needed to distribute. 

[Biplab]

If you add wx_pch.h file in NOPCH mode, it has no effect on PCH generation. It includes wx/wxprec.h file only.

That would be fine but you are not creating the wx_pch.h file at all. It is missing.

I found that stupid bug later. Thanks a lot for pointing that out. I'll fix it in next revision. 

wx Dev team does not suggest us to use static library for MSVC in some cases. I'm quoting the following line from src/common/string.cpp file.

Code

#if defined(__VISUALC__) && defined(_MT) && !defined(_DLL)
#  pragma message (__FILE__ ": building with Multithreaded non DLL runtime has a performance impact on wxString!")

This warning was one of the reason I took a longer route of embedding manifest file for MSVC 8 to exe file after the build is finished. And I think it would be better if you continue building wxPack with dynamic runtime lib. 

I have done some reading and a bit of testing and have determined that the impact for most uses is minimal. In my opinion you should be able to use the statically linked library with no other files to distribute. (Yes I know the Windows is coming with them more and more) and if you would be willing to use the runtime dll you will be willing to use wxWidgets as a dll as well. So I think this is the best compromise between speed and extra files needed to distribute. 

I'm not sure what is the exact performance impact. But if you are using dynamic CRT, then you do not need to use wxwidgets as DLL; you may use static wx lib too. That _DLL flag checks whether CRT is dynamic or not when Multi-threaded option is selected. For more info please visit the following link.

http://msdn2.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx

If you create static lib of wxWidgets using dynamic CRT, only external dependency will be your CRT and therefore you'll be able to solve dll distribution problem. 

[Biplab]

Here is another upgrade. This has some important fixes. So if you are using older revision, please download and use this revision.

Changes:

• Wizard now sets Appropriate wxWidgets lib order. But do not forget to add any necessary additional wx libs (Jpeg, Tiff, expat or regex) if you are using advanced lib (RichText, AUI, etc); wizard will not add them. Thanks to three_minute_hero for pointing this.
• Now XML and XRC lib can be selected separately.
• Wizard now stops compilation of wx_pch.h in Non-PCH project builds (This is a temporary fix, needs Improvement). Thanks to Ryan for pointing this.
• Wizard supports BCC 5.82 Compiler. You can now build wx app with it.

Known Issues:

• Does not support MSVC 7.1 or 6.
• PCH support needs improvement.

Some Informations:

BCC 5.82 Compiler: This compiler comes with Turbo C++ Explorer edition. Get it for free from (http://www.turboexplorer.com/cpp). To add the compiler to Code::Blocks, see my video tutorial.

wx lib order: Only 3 libraries are vulnerable to lib orders; RichText, DB_Grid and XRC. Their additional dependencies (partial) are -

• DB_Grid - wxbase_odbc, wxmsw_adv
• RichText - wxbase_xml, wxmsw_adv, wxmsw_html
• XRC - wxbase_xml, wxmsw_adv, wxmsw_html

By the way, you may also need to add JPEG, TIFF, Expat and Regex libraries if you add them. Sorry I could not find out their complete dependency chart. Any help would be greatly appreciated.

[attachment deleted by admin]