CodeBlocks includes for wxWidgsts

[Uskok]

Hi forum,

I am using wxWidgets with changed setup.h under ...\lib\gcc_dll\mswu\wx
Changes are:

Code

#ifdef NDEBUG
	#define wxDEBUG_LEVEL 0
#else
	#define wxDEBUG_LEVEL 2
#endif

#   define wxUSE_GRAPHICS_CONTEXT 1

and I have problem with compiling because the order of include directories are not corrected in the CB projects

Errors:
D:/Dev/wxWidgets-3.0.3/include/wx/event.h:399: undefined reference to `wxOnAssert(char const*, int, char const*, char const*, char const*)'
D:/Dev/wxWidgets-3.0.3/include/wx/event.h:399: undefined reference to `wxTrap()'

The include directories are defined as:
$(#WX30_64.include)
$(#WX30_64.lib)\gcc_dll$(WX_CFG)\msw$(WX_SUFFIX)

but it must be opposite, otherwise ...\wxWidgets-3.0.3\lib\gcc_dll\mswu\wx\setup.h is coming after ...\include\wx\msw\setup.h

In my opinion, the usage of the $(WX_CFG) is wrong. If I compare the logic as is done for the wx-config (windows version, WXCFG environment variable), the much flexible solution is to define
WX_CFG=gcc_dll  or completely without  WX_CFG and define library folder inside $(#WX30_64.lib)

For my project I have
$(#WX30_64.lib)\mswu
$(#WX30_64.include)

This allows multiple sets of library at the same time. I have something as:
...\lib\gcc481-x64_dll\mswu(d)
...\lib\gcc492-x64_dll\mswu(d)
...\lib\gcc510-x64_dll\mswu(d)
...\lib\vc_x64_dll\mswu(d)


Regards,

    Uskok

[oBFusCATed]

What is the purpose of the topic?
Are you proposing that we must change the wx project template?

[Uskok]

What is the purpose of the topic?
Are you proposing that we must change the wx project template?

No, the projects to generate CB have wrong include order.

[stahta01]

What is the purpose of the topic?
Are you proposing that we must change the wx project template?

No, the projects to generate CB have wrong include order.

Is this the CB wxWidgets wizard you are talking about?
Or the CB plugin wizard?
Or something else?

I am once more trying to update my wxWidgets wizard changes and could try to fix this issue if it is in that CB wizard.

Tim S.

[oBFusCATed]

No, the projects to generate CB have wrong include order.

Can you please rephrase this sentence, because I don't understand its meaning?
Are you talking about the projects in svn which are used to build codeblocks on windows?

[Uskok]

No, the projects to generate CB have wrong include order.

Can you please rephrase this sentence, because I don't understand its meaning?
Are you talking about the projects in svn which are used to build codeblocks on windows?

Yes, the project in svn used to build codeblocks under windows have the wrong order of the include files.
The include directories are defined as:
$(#WX30_64.include)
$(#WX30_64.lib)\gcc_dll$(WX_CFG)\msw$(WX_SUFFIX)

It must be opposite.
The same is for all version (WX, WX30, WX31, WX31_64)
You must include first ...\wxWidgets-3.0.3\lib\gcc_dll\mswu\wx\setup.h and not the version from ...\include\wx\msw\setup.h

This allows to have N parallel different versions of wxWidgets with different configuration (setup.h) and build with different compilers.

[oBFusCATed]

Can you provide a link to the wx documentation where this is explained and confirmed as a feature?

[stahta01]

Can you provide a link to the wx documentation where this is explained and confirmed as a feature?

I am 90% certain that the real issues is user error or the fact the user is using Visual Studio only header.

But, I do agree the order suggested would be better and slightly safer because of the people who copy or move wx/setup.h when they should not do that.

Tim S.

[Uskok]

Can you provide a link to the wx documentation where this is explained and confirmed as a feature?

From version 2.8.12 file ...\docs\msw\install.txt

Object and library directories
----------------------------------------------------------------

All object files produced during library build are stored in a directory under
build\msw. It's name is derived from build settings and CFG variable and from
compiler name. Examples of directory names:

  build\msw\bcc_msw            SHARED=0
  build\msw\bcc_mswdll         SHARED=1
  build\msw\bcc_mswunivd       SHARED=0, WXUNIV=1, BUILD=debug
  build\msw\vc_mswunivd        ditto, with Visual C++

Libraries and DLLs are copied into subdirectory of lib directory with
name derived from compiler and static/DLL setting and setup.h into directory
with name that contains other settings:

  lib\bcc_msw
  lib\bcc_lib\msw\wx\setup.h
  lib\bcc_dll
  lib\bcc_dll\msw\wx\setup.h
  lib\bcc_lib
  lib\bcc_lib\mswunivd\wx\setup.h
  lib\vc_lib
  lib\vc_lib\mswunivd\wx\setup.h

Each lib\ subdirectory has wx subdirectory with setup.h as seen above.
This file is copied there from include\wx\msw\setup.h (and if it doesn't exist,
from include\wx\msw\setup0.h) and this is the copy of setup.h that is used by
all samples and should be used by your apps as well. If you are doing changes
to setup.h, you should do them in this file, _not_ in include\wx\msw\setup.h.

If you set CFG to something, the value is appended to directory names. E.g.
for CFG=MyBuild, you'll have object files in

  build\msw\bcc_mswMyBuild
  build\msw\bcc_mswdllMyBuild
  etc.

and libraries in

  lib\bcc_libMyBuild
  lib\bcc_dllMyBuild
  etc.

By now it is clear what CFG is for: builds with different CFG settings don't
share any files and they use different setup.h files. This allows you to e.g.
have two static debug builds, one with wxUSE_SOCKETS=0 and one with sockets
enabled (without CFG, both of them would be put into same directory and there
would be conflicts between the files).

[stahta01]

Why do you think the header "wx/msw/setup.h" will be used instead of "wx/setup.h"?

I do think changing the order of search paths is a good idea; but, I do not see your logic as valid.

I would change it because I am guessing it would be a tiny bit faster building; but, I have never really seen any build speed improvements when I first tried it several years ago. But, my hardware is old and its speed various a lot on each build test.

Tim S.
 

[stahta01]

Link to a patches I am working on for the CB wxWidgets wizard https://sourceforge.net/p/codeblocks/tickets/508/

Note: I still do not understand why you think there is a problem building Code::Blocks that the project needs patched.
I agree the order you suggest is better; but, unless you manually copied an setup.h under the wx folder you should not normally get a build problem.

If you have a real problem building Code::Blocks post your build log with the problem.

Tim S.

[Uskok]

Why do you think the header "wx/msw/setup.h" will be used instead of "wx/setup.h"?

I do think changing the order of search paths is a good idea; but, I do not see your logic as valid.

I would change it because I am guessing it would be a tiny bit faster building; but, I have never really seen any build speed improvements when I first tried it several years ago. But, my hardware is old and its speed various a lot on each build test.

Tim S.

You are right. I putted wrong path. The correct is as you wrote ..\lib\gcc_dll\mswu\wx\setup.h
Wrong copy paste.
It is not the question of speed up the compilation time, it is the usage of the wrong header file. The nice trick what is done in wxWidgets is to tune your own copy of the setup.h and it is dedicated to the build. You can have N parallel build under lib folder, different compiler and version with different options.

[Uskok]

Link to a patches I am working on for the CB wxWidgets wizard https://sourceforge.net/p/codeblocks/tickets/508/

Note: I still do not understand why you think there is a problem building Code::Blocks that the project needs patched.
I agree the order you suggest is better; but, unless you manually copied an setup.h under the wx folder you should not normally get a build problem.

If you have a real problem building Code::Blocks post your build log with the problem.

Tim S.

Hi Tim,

Take  a look on the build process:


D:\Dev\MinGW-TDM-510-x64>mingwvars.bat

Setting up environment for using MinGW with GCC from D:\Dev\MinGW-TDM-510-x64\.

D:\Dev\MinGW-TDM-510-x64>cd D:\Dev\wxWidgets-3.0.3\build\msw
D:\Dev\wxWidgets-3.0.3\build\msw>mingw32-make -f makefile.gcc
if not exist gcc_mswud mkdir gcc_mswud
if not exist ..\..\lib\gcc_lib mkdir ..\..\lib\gcc_lib
if not exist ..\..\lib\gcc_lib\mswud mkdir ..\..\lib\gcc_lib\mswud
if not exist ..\..\lib\gcc_lib\mswud\wx mkdir ..\..\lib\gcc_lib\mswud\wx
if not exist ..\..\lib\gcc_lib\mswud\wx\setup.h copy ..\..\include\wx\msw\setup.h ..\..\lib\gcc_lib\mswud\wx\setup.h
        1 file(s) copied.
if not exist ..\..\lib\gcc_lib\mswud\wx\msw mkdir ..\..\lib\gcc_lib\mswud\wx\msw
gcc -E "..\..\include\wx\msw\genrcdefs.h" > "..\..\lib\gcc_lib\mswud\wx\msw\rcdefs.h"
gcc -c -o gcc_mswud\wxregex_regcomp.o -g -O0 -mthreads  -DHAVE_W32API_H -DNDEBUG -I..\..\include -I..\..\lib\gcc_lib\mswud -D__WXMSW__  -D_U
NICODE   -MTgcc_mswud\wxregex_regcomp.o -MFgcc_mswud\wxregex_regcomp.o.d -MD -MP ../../src/regex/regcomp.c
gcc -c -o gcc_mswud\wxregex_regexec.o -g -O0 -mthreads  -DHAVE_W32API_H -DNDEBUG -I..\..\include -I..\..\lib\gcc_lib\mswud -D__WXMSW__  -D_U
NICODE   -MTgcc_mswud\wxregex_regexec.o -MFgcc_mswud\wxregex_regexec.o.d -MD -MP ../../src/regex/regexec.c
gcc -c -o gcc_mswud\wxregex_regerror.o -g -O0 -mthreads  -DHAVE_W32API_H -DNDEBUG -I..\..\include -I..\..\lib\gcc_lib\mswud -D__WXMSW__  -D_
UNICODE   -MTgcc_mswud\wxregex_regerror.o -MFgcc_mswud\wxregex_regerror.o.d -MD -MP ../../src/regex/regerror.c
gcc -c -o gcc_mswud\wxregex_regfree.o -g -O0 -mthreads  -DHAVE_W32API_H -DNDEBUG -I..\..\include -I..\..\lib\gcc_lib\mswud -D__WXMSW__  -D_U
NICODE   -MTgcc_mswud\wxregex_regfree.o -MFgcc_mswud\wxregex_regfree.o.d -MD -MP ../../src/regex/regfree.c
if exist ..\..\lib\gcc_lib\libwxregexud.a del ..\..\lib\gcc_lib\libwxregexud.a
ar rcu ..\..\lib\gcc_lib\libwxregexud.a gcc_mswud\wxregex_regcomp.o gcc_mswud\wxregex_regexec.o gcc_mswud\wxregex_regerror.o gcc_mswud\wxreg
ex_regfree.o
ranlib ..\..\lib\gcc_lib\libwxregexud.a
gcc -c -o gcc_mswud\wxzlib_adler32.o -g -O0 -mthreads  -DHAVE_W32API_H -DNDEBUG   -MTgcc_mswud\wxzlib_adler32.o -MFgcc_mswud\wxzlib_adler32.
o.d -MD -MP ../../src/zlib/adler32.c
gcc -c -o gcc_mswud\wxzlib_compress.o -g -O0 -mthreads  -DHAVE_W32API_H -DNDEBUG   -MTgcc_mswud\wxzlib_compress.o -MFgcc_mswud\wxzlib_compre
ss.o.d -MD -MP ../../src/zlib/compress.c
gcc -c -o gcc_mswud\wxzlib_crc32.o -g -O0 -mthreads  -DHAVE_W32API_H -DNDEBUG   -MTgcc_mswud\wxzlib_crc32.o -MFgcc_mswud\wxzlib_crc32.o.d -M
D -MP ../../src/zlib/crc32.c
makefile.gcc:5720: recipe for target 'gcc_mswud\wxzlib_crc32.o' failed
mingw32-make: *** [gcc_mswud\wxzlib_crc32.o] Error 3

D:\Dev\wxWidgets-3.0.3\build\msw>


The first copy of setup.h is done in make self. wxWidgets developers made nice trick. You will get the master copy, if it is the first run of make.
Then you can change what you like to tune and rebuild the library.

[stahta01]

So, are you having a problem building Code::Blocks or not?

Tim S.

[Uskok]

So, are you having a problem building Code::Blocks or not?

Tim S.

Of course, as is written in my first entry of the theme. I have done some investigation.
My assumption of the problem was wrong.
..\..\include\wx\msw\setup.h is not used during the build process only ..\..\lib\gcc_lib\mswu(d)\wx\setup.h
That means, the current order of includes can be as it is.

The solution for my problem is to use "-O2 -DNDEBUG" instead "-g" for real release inside cb_release_type. -DNDEBUG removes my problem with build of Code::Blocks.


Thanks for support.