A note about the Windows builds

[280Z28]

These commands are better for building the ANSI and Unicode versions of wxWidgets (respectively) as it separates the output directories from each other.

Code Select Expand

mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=0 CFG=NonUnicode VENDOR=cb clean
mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=0 CFG=NonUnicode VENDOR=cb

Code Select Expand

mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 CFG=Unicode VENDOR=cb clean
mingw32-make -f makefile.gcc USE_XRC=1 SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1 CFG=Unicode VENDOR=cb

This comes from a discussion I had with someone in another thread but I forget which one it was now.

[takeshimiya]

I compile it just that way. It remains to be seen if the CFG is usefull in that case.
For only doing between Unicode/NonUnicode it isn't worth. Unleast the libraries start to make problems between versions.

[thomas]

These commands are not better. This is a valid way of building wxWidgets, but it is not better.

It is absolutely no problem to have both shared libraries (unicode and non-unicode) in the same directory (they have different names), and you do not need to modify the project file  before you compile Code::Blocks.

Using CONF makes sense if you compile different versions of wxWidgets which have different feature sets (other than Unicode).
For example when compiling one "complete" version and one version that does not include image loading and odbc, the output libraries will have the same name, so they have to be separated, obviously.

In all other cases it is easier (and less confusing for inexperienced users) to keep things like they are.

[takeshimiya]

Agreed.

[tiwag]

i would propose to change all CB project files in SVN (also in /plugins/contrib/* ) to use the standard wxwidgets pathes.
that means: set the WX_CFG by default to "" (empty string)
if someone is in need to use another directory he can edit it by himself - and knows presumably about.

The inconsistent usage of WX_CFG in these project files (sometimes set to "NonUnicode", sometimes set to "" ) is
really annoying and last not least a reason, why some ( less experienced ) users couldn't build a SVN version by themself.

[takeshimiya]

I can add that if you want to remove the zillion warnings "No attribute... " produced under MinGW, just open wxWidgets-2.6.2\build\msw\makefile.gcc and do a search&replace of all "-Wall" and "-W" (check only the whole word) and replace them with " ".

From what I've read from word of wx core developers, those zillion "No attribute... " warnings are produced by a bug in specifics version of MinGW.

[thomas]

Actually they're produced because they're not using it properly...


EDIT:
In case you're interested in the exact cause, it is the use of __declspec.
This is MSVC syntax, not valid for MinGW. Who said using compiler-specific stuff was bad practice?

Anyway, as a workaround for the ignorant, MinGW has a __declspec macro, which looks like

Code Select Expand

#define __declspec(x) __attribute__ (( x )) Maybe it looks slightly different, I did not learn it by heart, but it should be about like this 

But... they do not only use compiler-specifics in wxWidgets, they also use them in places where they should not, hence the warning "Attributes are only honoured..."


And you all were bashing me for using attributes and underscores... 

[takeshimiya]

Well, that gives a leson, using compiler specific extensions should be taken with a lot of care.

EDIT: But actually wx uses this:

Code Select Expand

#if defined(__WXMSW__)
    /*
       __declspec works in BC++ 5 and later, Watcom C++ 11.0 and later as well
       as VC++ and gcc
     */
#    if defined(__VISUALC__) || defined(__BORLANDC__) || defined(__GNUC__) || defined(__WATCOMC__)
#        define WXEXPORT __declspec(dllexport)
#        define WXIMPORT __declspec(dllimport)
#    else /* compiler doesn't support __declspec() */
#        define WXEXPORT
#        define WXIMPORT
#    endif
#endif

It is not correct for MinGW?

[thomas]

Compiler specifics are absolutely ok, you only have to write an evil macro that disapbles or mangles the compiler-specific on platforms that don't support it.
It is a shame actually that you really have to use macros here...

[280Z28]

I just remember when I had it set up with the default paths I had to modify the .cbp file (or move the output *.a files from gcc_dll to gcc_dll/msw(u) ), but when I set CFG, it worked without modifications or moving anything. Have you since changed the library directories in the project file?

[tiwag]

I just remember when I had it set up with the default paths I had to modify the .cbp file (or move the output *.a files from gcc_dll to gcc_dll/msw(u) )...

you're right. this is another bug in the *.cbp project files and was discussed a few times already.
the <Linker> section contains the bogus "gcc_dll/msw" instead of the correct standard-library-path "gcc_dll"
(presumably a copy'n paste bug  )

Code Select Expand

<Linker>
<Add library="wxmsw26"/>
<Add directory="sdk\tinyxml"/>
<Add directory="$(WX_DIR)\lib\gcc_dll\msw"/>            <------------------ !!!!!!!!!!!
<Add directory="$(WX_DIR)\lib\gcc_dll$(WX_CFG)"/>
</Linker>

therfore i expand my proposal to completely remove the standard-pathes for wxwidgets in both,
<Compiler> as well as in <Linker> sections and set the WX_CFG custom variable by default to "" (empty string).

[thomas]

These are the current settings:

Code Select Expand

CodeBlocks-NewBuild.cbp
------------------------
compiler:
$(#WX.include)
$(#WX.lib)\gcc_dll\msw
$(#WX.lib)\gcc_dll$(WX_CFG)\msw
$(#WX)\contrib\include
sdk\wxscintilla\include
sdk\as\include

linker:
wxmsw26

sdk\tinyxml
$(#WX.lib)\gcc_dll
$(#WX.lib)\gcc_dll$(WX_CFG)



CodeBlocks-NewBuild-UNI.cbp
----------------------------
compiler:
$(#WX.include)
$(#WX.lib)\gcc_dll\msw$(WX_SUFFIX)
$(#WX.lib)\gcc_dll$(WX_CFG)\msw$(WX_SUFFIX)
$(#WX)\contrib\include
sdk\wxscintilla\include
sdk\as\include

linker:
wxmsw26$(WX_SUFFIX)

sdk\tinyxml
$(#WX.lib)\gcc_dll
$(#WX.lib)\gcc_dll$(WX_CFG)

The unified project does not require you to change any paths, no matter whether you want to build ANSI or Unicode versions. That is, supposed per project variables work... which is the case now.
As you can see, WX_CONF has been kept for backwards-compatibility.  But like tiwag said, it is really obsolete and causes more confusion than it is worth.

EDIT:
Hmmm... I just spotted that there is one stale linker path in every config. But luckily that doesn't matter in this case - the lib therein has a different name.

[280Z28]

Let's make the only .cbp file have these directories and be done with it. Make the default WX_SUFFIX="" and WX_CFG is no more. Does that work? It'll make it where we have one simple set of build instructions that work for everyone, unicode and ANSI. 

Code Select Expand


Compiler
--------
$(#WX.include)
$(#WX.lib)\gcc_dll\msw$(WX_SUFFIX)
$(#WX)\contrib\include
sdk\wxscintilla\include
sdk\as\include

Linker
------
sdk\tinyxml
$(#WX.lib)\gcc_dll

Resource compiler
-----------------
$(#WX.include)

Link libs (all non-windows libs), don't put lib and .a, and for wxWidgets, in all places specify it like this:
--------------------------------
wxmsw26$(WX_SUFFIX)
codeblocks
wxscintilla

Link libs (all native windows libs), keep the lib*.a format

[thomas]

That will probably work. It is basically how the unified project looks now (except for the extra path).

But changing the project file right now does not make a lot of sense, considering the upcoming changes.

[tiwag]

... considering the upcoming changes.

explain it please !