My God! So many build types... Which one do I choose? Topic is solved

[davebee]

Greetings from a newbie.

So, I downloaded wxMSW-2.6.3, eager to start using this amazing framework for my new project. I fired up my compiler (VC++ 6 SP6 on Windows 2000) to build the wxWidgets libraries and... I was stunned: so many build options, which one do I choose?

I mean, I counted at least 14:

Win32 DLL Universal Release
Win32 DLL Universal Debug
Win32 DLL Unicode Release
Win32 DLL Unicode Debug
Win32 DLL Release
Win32 DLL Debug
Win32 Universal Unicode Release
Win32 Universal Unicode Debug
Win32 Universal Release
Win32 Universal Debug
Win32 Unicode Release
Win32 Unicode Debug
Win32 Release
Win32 Debug

OK - so I know what the difference is between 'Release' and 'Debug' and there really are only 7 build types. I also know the difference between DLL and Static, so I further narrowed it down to only 4:

Win32 Universal Unicode Debug
Win32 Universal Debug
Win32 Unicode Debug
Win32 Debug

I also learned (from http://www.wxwidgets.org/about/wxuniv.htm) that at the moment I don't want wxUniversal, so I am basically left with only 2 build types:

Win32 Unicode Debug
Win32 Debug

Good. But I am still confused.

I think that I need to have the ability to support Unicode, since my application will be processing text copied from web pages (which I don't know at compile time whether they are encoded ANSI or Unicode).

However, I left the relevant setting in setup.h at its default:

#define wxUSE_UNICODE 0

since my understanding is that setting wxUSE_WCHAR_T to 1 is sufficient to support Unicode. (is this correct?)

My question, that is: If I build 'Win32 Debug' only, while wxUSE_WCHAR_T (in setup.h) is set to 1, will I be able to support Unicode in my application?

If not, do I have to both set wxUSE_UNICODE (in setup.h) to 1 and build 'Win32 Unicode Debug'?

What is the "magic combination" of build type and setup.h setting that will allow me to achieve what I am trying to accomplish?

Thanks,
Dave

[Xangis]

I'd recommend setting wxUSE_UNICODE 1 and building Win32 Unicode debug|release if you're going to be using unicode in your project.

One thing to note, when using wxWidgets in unicode mode, you're going to want to use the _() macro on all of your strings, i.e. _("This is a string"), in order to make sure that the unicode translates properly. The nice thing about that macro is that when it's used with a non-unicode build it leaves the string unchanged.

You can also build a non-unicode build and switch later if you find that you need it relatively painlessly if you get into the habit of using that macro.

[davebee]

Xangis, thanks for your reply.

I'd recommend setting wxUSE_UNICODE 1 and building Win32 Unicode debug|release if you're going to be using unicode in your project.

If I do that, will I be able to process regular ANSI (8-bit) encoded strings using the same build?

One thing to note, when using wxWidgets in unicode mode, you're going to want to use the _() macro on all of your strings...

Actually, _() is a function, _T() and wxT() are macros - and you're right, the wxWidgets Manual strongly suggests that.

You can also build a non-unicode build and switch later if you find that you need it relatively painlessly if you get into the habit of using that macro.

You are right, but I would prefer to know as much as possible before getting into lengthy trial-and-error process. I also prefer to minimize the number of wxWidgets build types, if only for maintenance simplicity (less compilations and the need to sync them if I ever decide to modify one setting in setup.h).

I am still confused and while researching for an answer I discovered that I am not the only one. The poster in this thread says:

if you enable wxUSE_UNICODE in the original setup.h, and build all eight configurations, you're going to have eight unicode builds instead of four ANSI and four Unicode. If you don't enable it, then you would ostensibly have eight ANSI builds, but since it defines _UNICODE automatically, that's not true. I think wxUSE_UNICODE should be abandoned in favor of plain old _UNICODE.

Indeed, it is very confusing.

Dave

[davebee]

And here there is a description how to support Unicode without ever compiling for unicode...

You have two options: one, you can use unicode build of wxWindows
(wxUSE_UNICODE, only Win32) and convert expat's output to wxString
this way:

wxString string(expat_buf, wxConvUTF8, expat_buf_len);

Or you can use ANSI build (wxUSE_UNICODE=0,wxUSE_WCHAR_T=1) and do two-step conversion:

// copy UTF-8 expat's output to wxString for convenience:
wxString utf8(expat_buf, expat_buf_len);
// convert utf8 to wchar_t representation and then back to iso:
wxCSConv cs("iso-8859-1");
wxString iso(utf8.wc_str(wxConvUTF8), cs);

Note that the last line is *lossy* convertion because utf8 may contain (encoded) any of Unicode characters, while iso only has space for 256 of them! You can do this only if you're sure the XML file in question only contains iso-8859-1 strings.

Interesting - and confusing, too.

[davebee]

And... I think that I finally found the authoritative answer:

...what happens with _UNICODE is that it overrides wxUSE_UNICODE definition in setup.h. This allows you to use the same setup.h for both ANSI and Unicode builds: even though wxUSE_UNICODE is 0 in setup.h, if _UNICODE is defined it is overridden and redefined as 1.

...you don't have to edit anything for wxUSE_UNICODE because _UNICODE overrides it and so everything just works by default.

So, it seems that I will start with ANSI build only and see if I can get away with it - even for processing Unicode text.

Dave

[Jorg]

davebee,

You just have to consider this. When building in Unicode, ANSI always works. Not the other way around. When I develop something I make sure it works in Unicode because that is most likely to give problems. Why use Unicode over Ansi ? It is actually only relevant when you accept input from the user that can contain characters above the range of special characters. For example when the user cannot enter special characters in his name, and you are ok with that, you do not use Unicode. But when you want to offer a chinese guy, german guy or whatever nationality the chance to use their native writing, unicode is the way to go.

Other then that, unicode is more modern.

- Jorgen

[davebee]

When building in Unicode, ANSI always works. Not the other way around.

Jorg, thank you very much for your answer. You just gave me the missing piece that I needed: I have never developed in Unicode (:oops:) and so I have no experience in it and I don't know what to expect. Thus, I didn't know that when building in Unicode, ANSI works. Especially when the comments in setup.h say:

// Recommended setting: 0 (unless you only plan to use Windows NT/2000/XP)
#ifndef wxUSE_UNICODE
#define wxUSE_UNICODE 0
#endif

My understanding from this is that once I build in Unicode, it will not work for Windows 98/ME (Windows 95 is dead so I don't care much about it). But now that you say that if I build in Unicode, ANSI will work too, I feel more inclined to build Unicode.

There is still the confusion though about the purpose of the setting wxUSE_UNICODE (in setup.h), as it seems that the _UNICODE macro in the .dsp project files override it anyway. Wow, I didn't know it would be so complex.

Thanks,
Dave

[Jorg]

You will still have to recompile your app. What I meant with ANSI will work once building in UNICODE is that the compiler is more forgiving in ANSI, more strict in UNICODE. So once you got it going with UNICODE, recompiling it in ANSI is a breeze. The other way around, porting an app to UNICODE which is ANSI is more cumbersome, wxT(" ...") you often forget, string pointers that cannot be converted implicitly anymore, it all depends on your preference, but when you choose UNICODE now, recompiling later will not be hard.

- Jorgen

[ONEEYEMAN]

Jorg,
I agree with you that UNICODE build always works in ANSI one.
However, I don't see how you can build UNICODE with ODBC on wxGTK

I guess you have some magic performed....

Thank you.

[Jorg]

I never compiled ODBC, that's the magic I always use wxSqlLite. But indeed when the libs compiled against are not supporting it, it is safer to stay in ANSI.

- Jorgen

[davebee]

Just to let you know, I built my application in "Win32 DLL Unicode Debug" mode without setting wxUSE_UNICODE to 1 in setup.h.

It works perfectly (supporting Unicode and ANSI) !

I will shortly mark this thread as resolved.

Thank you all for your guiding comments.

Dave

[tiwag]

Just to let you know, I built my application in "Win32 DLL Unicode Debug" mode without setting wxUSE_UNICODE to 1 in setup.h.
It works perfectly (supporting Unicode and ANSI) !

maybe i'm wrong, but if you do that i would expect that you have built an ANSI build

[davebee]

maybe i'm wrong, but if you do that i would expect that you have built an ANSI build

No, I didn't build an ANSI build. Instead, whenever I need to handle non-unicode data, I first conver it to unicode using the wxString constructor

wxString what(char*, *wxConvCurrent)

And then handle it as unicode.

Dave

[tiwag]

yes, that's what i would expect,
you have an ansi-build (means it uses ansi library functions i.e. MessagBoxA instead of MessageBoxW) with standard usage of w_char type.
is that correct ?