Standard build environment: wx-2.6/unicode

[mandrav]

As of today, all developers are advised to use wx-2.6/unicode for building C::B. This will be our officially supported platform and everyone should use it. Most (if not all) unicode related showstopper bugs have been fixed. By using the unicode version, more subtle unicode related bugs can be caught and dealt with.

I have updated all project files (*-NewBuild.cbp) to use only WX_CFG (defaults to empty) and WX_SUFFIX (defaults to 'u') macros.

[takeshimiya]

Good step towards i18n

For the stable official builds and SVN win32 unofficial builds, I'd suggest enabling MSLU support with libunicows.
So only one executable would be needed, and it will work even on Windows 9x with Unicode support.

If some of you have doubts about MSLU working well, the last weeks I've been using it with MSLU support.
For example, poEdit is distributed that way (UNICODE=1, MSLU=1).

[killerbot]

what's the correct way to build the wx dll now (should an update to the wiki be done )??

[takeshimiya]

Previous:
mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=0 VENDOR=cb

Now:
mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 VENDOR=cb

[killerbot]

just to be sure : we all need this new dll, together with it's new setup.h, don't we ?

Since I noticed the following :
 - cb still builds (only wx ansi was on my system)
 - devpak plug-in does not build with wx ansi -> compiler error : does not find the setup.h (as expected)

Strange that cb still builded ?

[killerbot]

devpak plug-in warnings :
 ../../../sdk/sdk.h.gch not used because wxUSE_UNICODE is defined.

I hope this is ok, how to get rid of that warning ??

[killerbot]

okay okay, seems I am not having a good day.
It is obvious I should use CodeBlocks-NewBuild-UNI.cbp and not the CodeBlocks-NewBuild.cbp (so the previous things I noticed should be considered garbage).

Question : since the official product will be the unicode build, does it make sense to keep the build file for the ansi one ??

[tiwag]

Now:
mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 VENDOR=cb

i would propose to use for the future a slightly modified build, with added version number of used wxwidgets version number
otherwise the produced shared library has the same name when using wx261 or wx262 which sometimes is annoying.

my proposal for future usage,
append wxwidgets version+release to VENDOR string

for wxwidgets 2.6.1

Code

mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 VENDOR=cb261

for wxwidgets 2.6.2

Code

mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 VENDOR=cb262

and so on ... ( when wxwidgets community releases newer versions then ... )

this would also clearify which wxwidgets version was used by a specific developer ( thinking of SVN binaries downloads )

What's your opion ?

[tiwag]

As of today, all developers are advised to use wx-2.6/unicode for building C::B. This will be our officially supported platform and everyone should use it. Most (if not all) unicode related showstopper bugs have been fixed. By using the unicode version, more subtle unicode related bugs can be caught and dealt with.

I have updated all project files (*-NewBuild.cbp) to use only WX_CFG (defaults to empty) and WX_SUFFIX (defaults to 'u') macros.

Hi Yiannis

i've just now built a new wx262 unicode build of CB and got these warnings

did you notice it too ?!

[edit]
same problem

src\plugins\contrib\source_exporter\wxPdfDocument\src\pdffont.cpp:910

Code

    if (c >= 0 && c < 128)

[attachment deleted by admin]

[mandrav]

Hi Yiannis

i've just now built a new wx262 unicode build of CB and got these warnings

did you notice it too ?!

Yes I did.

[cyberkoa]

A very good news to me because I am all the while using unicode build 

I have some problem compiling manager.cpp when building the wxPropgrid target which is newly added , I wonder anybody have the same problem ?


EDIT : I do not have problem building propgrid that was in the wxSmith last time , I have tried to check and quite confirm that the wxPropgrid in sdk and the propgrid in wxsmith is identical.


[attachment deleted by admin]

[killerbot]

Yiannis,

Could you take a look at the cbp file of the contributed "copystrings" -> does not build in the unicode settings.
I can also take a look at it tomorrrow, but since you are so fast ...

Lieven

[mandrav]

Yiannis,

Could you take a look at the cbp file of the contributed "copystrings" -> does not build in the unicode settings.
I can also take a look at it tomorrrow, but since you are so fast ...

Lieven

Done.

[killerbot]

would almost say "too fast"  :shock:   

Yes : it builds (now how's that for a test)

[rickg22]

heheh I added that plugin in a hurry My intention is to turn it into a big refactory plugin so that you can move all your strings into a separate namespace. It's a pretty basic functionality, but copying the strings manually is a mess.

[cyberkoa]

I hv solved my problem , it is because I have installed wxpropgrid using the setup file from the wxpropgrid website to study the example to add in bitmap support in wxSmith last time.

the wxpropgrid is installed in the $(#WX.include) therefore , when compile , it includes the wrong version of include file.