These commands are better for building the ANSI and Unicode versions of wxWidgets (respectively) as it separates the output directories from each other.
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
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. :(
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.
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.
Agreed.
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.
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.
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 #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... 8)
Well, that gives a leson, using compiler specific extensions should be taken with a lot of care.
EDIT: But actually wx uses this:
#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?
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...
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?
Quote from: 280Z28 on December 22, 2005, 08:39:41 PM
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 8) )
<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).
These are the current settings: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.
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. 8)
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
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.
Quote from: thomas on December 22, 2005, 09:42:55 PM
... considering the upcoming changes.
explain it please !
Quote from: thomas on December 22, 2005, 08:58:04 PM
These are the current settings...
this ok now, but it can be as it is since a few days only ... for month it contained the bogus gcc_dll/msw in the linker section.
anyway, good that this was cleaned...
but seriously - take a closer look in the templates and pugins/contrib/* directories
there you can see that the usage of WX_CFG is totally mixed and that's confusing
finally : @thomas - thanks for cleaning the current situation !
Quote from: tiwag on December 22, 2005, 10:21:04 PM
this ok now, but it can be as it is since a few days only ...
About 2 days, 23 hours :)
Quote from: tiwag on December 22, 2005, 10:15:58 PMexplain it please !
After changing global user variables, it will make sense to change the Code::Blocks projects. I think it would be unnecessarily complicated to change them now and then again in a few days (supposed I ever find out how to add a
wxGrid to that darn dialog without getting an exception...).
For the moment, the project file works, so I would not touch it unless necessary.
I don't know for what you'll be using wxGrid, but you could try with another simmilar like wxListCtrl, or wxProperyGrid.
Quote from: Takeshi Miya on December 23, 2005, 09:40:47 AM
I don't know for what you'll be using wxGrid, but you could try with another simmilar like wxListCtrl, or wxProperyGrid.
Actually wxPropertyGrid is *exactly* what I need, I looked at that, too. But since it is not a part of wxWidgets, that would mean adding another third party library to the build just for one dialog. And it would still have to be added manually, you can't just put it into the XRC file.
wxListCtrl only displays one column, so it is not usable for that purpose (except with yet another dialog for every edit).
Quote from: thomas on December 23, 2005, 01:32:33 PM
Quote from: Takeshi Miya on December 23, 2005, 09:40:47 AM
I don't know for what you'll be using wxGrid, but you could try with another simmilar like wxListCtrl, or wxProperyGrid.
Actually wxPropertyGrid is *exactly* what I need, I looked at that, too. But since it is not a part of wxWidgets, that would mean adding another third party library to the build just for one dialog. And it would still have to be added manually, you can't just put it into the XRC file.
wxListCtrl only displays one column, so it is not usable for that purpose (except with yet another dialog for every edit).
wxPropertyGrid is already in the source as part of wxSmith. You could move that folder to the sdk folder or something? Just a random idea :)
Might be worth a consideration, if that doesn't break stuff.
Quote from: thomas on December 23, 2005, 02:52:07 PM
Might be worth a consideration, if that doesn't break stuff.
Just make a copy of it in svn for now, and then tell (wxSmith's maintainer) to remove the copy from the wxSmith folder once he's updated his project to point to the copy you made. :)
I would say that would be really good, because wxPropertyGrid in some other parts of C::B will do a very good job (like in the Compiler flags, separated by categories, and so on).
Afraid it will not... at least not as it looks right now. When added to the panel, it produces really nasty drawing errors, and it has the same resizing problem as wxGrid. Worse yet, it shows in 16x16 unless you explicitely give a fixed size... If you specify the dialog as the property grid's parent (instead of a panel), it draws really fine, albeit over all other controls, and not in the correct place either...
Maybe you are not thought to manually add items to a XRC created dialog at all (although I cannot think of a reason not to), or maybe I just don't know how to do it properly... either way, it does not work as easily as one would expect. The compiler flags dialog is created from XRC too, so it will have the same problem.
:(
Can I bring this thread back to the build process
Quote from tiwag December 22, 2005, 12:48:42 PMQuoteThe 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.
As a less experience user who has been compiling the svn version I would like to suggest that as changes are made to the build process the build instructions in svn trunck should be kept reasonably up to date and a little more detailed. I don't think it needs quite the detail of thomas' Compiling CodeBlocks for Windows ( ANSI and Unicode) from December 19, 2005, 10:47:44 AM - http://forums.next.codeblocks.org/index.php?topic=1701.0 , but the basic instructions.
It may be that you do not want to encourage less experience user to try the svn version, but I would have thought more testers would be better. From my point of view the features that interest me most are constantly improving and I want to be up to date with this.
The cause of most of my confusion was instructions about compiling wxwidgets with VENDOR=cb option and then moving to a seperate folder, which appears in many places in the wiki and the forum.
There does seem to be some sense in maintaining a specific codeblocks wxwidgets dll because you may not always want to compile codeblocks with the latest wxwidgets but may want it for other projects. Perhaps the best answer is to use a seperate tree forthe codeblocks version of wxwidgets (lib and include).
Yeah that page has to be cleaned up. It's a patchwork of many different ways of building over time. The part about moving or renaming directories is not needed, as this can be done by passing CFG=Unicode or CFG=NonUnicode. In addition, the CFG flag should probably be ommitted, unless you do want seperate codeblocks and other wxwidgets dlls -- just having Unicode and ANSI wxwidgets dlls in the same directory is supported and works fine. Btw, it is a wiki, so anyone can make changes to it -- the reason it isn't always up to date like larger project (uhhh kde or something) is time commitment (although code improvements are rapidly added to the SVN repository in preparation for a 1.0 release).