Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

CodeBlocks includes for wxWidgsts

<< < (2/3) > >>

Uskok:

--- Quote from: oBFusCATed on January 11, 2018, 11:09:18 pm ---
--- Quote from: Uskok on January 11, 2018, 08:32:13 pm ---No, the projects to generate CB have wrong include order.

--- End quote ---
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?

--- End quote ---

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:

--- Quote from: oBFusCATed on January 12, 2018, 12:11:09 am ---Can you provide a link to the wx documentation where this is explained and confirmed as a feature?

--- End quote ---

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:

--- Quote from: oBFusCATed on January 12, 2018, 12:11:09 am ---Can you provide a link to the wx documentation where this is explained and confirmed as a feature?

--- End quote ---

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.
 

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version