Author Topic: A note about the Windows builds  (Read 16889 times)

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
A note about the Windows builds
« on: December 22, 2005, 02:14:48 am »
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]
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]
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. :(
« Last Edit: December 22, 2005, 02:21:20 am by 280Z28 »
78 280Z, "a few bolt-ons" - [email protected]
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
Re: A note about the Windows builds
« Reply #1 on: December 22, 2005, 02:56:54 am »
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.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: A note about the Windows builds
« Reply #2 on: December 22, 2005, 09:20:55 am »
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.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
Re: A note about the Windows builds
« Reply #3 on: December 22, 2005, 06:22:01 pm »
Agreed.

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: A note about the Windows builds
« Reply #4 on: December 22, 2005, 06:48:42 pm »
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.

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
Re: A note about the Windows builds
« Reply #5 on: December 22, 2005, 07:59:33 pm »
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.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: A note about the Windows builds
« Reply #6 on: December 22, 2005, 08:05:47 pm »
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]
#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)
« Last Edit: December 22, 2005, 08:15:07 pm by thomas »
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
Re: A note about the Windows builds
« Reply #7 on: December 22, 2005, 08:16:28 pm »
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]
#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?
« Last Edit: December 22, 2005, 08:20:58 pm by Takeshi Miya »

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: A note about the Windows builds
« Reply #8 on: December 22, 2005, 08:19:39 pm »
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...
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: A note about the Windows builds
« Reply #9 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) ), but when I set CFG, it worked without modifications or moving anything. Have you since changed the library directories in the project file?
78 280Z, "a few bolt-ons" - [email protected]
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: A note about the Windows builds
« Reply #10 on: December 22, 2005, 08:50:13 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) )

Code: [Select]
<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).


Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: A note about the Windows builds
« Reply #11 on: December 22, 2005, 08:58:04 pm »
These are the current settings:
Code: [Select]
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.
« Last Edit: December 22, 2005, 09:02:24 pm by thomas »
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: A note about the Windows builds
« Reply #12 on: December 22, 2005, 09:29:15 pm »
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)

Code: [Select]
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
« Last Edit: December 22, 2005, 09:34:01 pm by 280Z28 »
78 280Z, "a few bolt-ons" - [email protected]
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: A note about the Windows builds
« Reply #13 on: December 22, 2005, 09:42:55 pm »
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.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: A note about the Windows builds
« Reply #14 on: December 22, 2005, 10:15:58 pm »
... considering the upcoming changes.
explain it please !

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: A note about the Windows builds
« Reply #15 on: December 22, 2005, 10:21: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 !

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: A note about the Windows builds
« Reply #16 on: December 22, 2005, 10:29:27 pm »
this ok now, but it can be as it is since a few days only ...
About 2 days, 23 hours  :)


explain 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.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
Re: A note about the Windows builds
« Reply #17 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.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: A note about the Windows builds
« Reply #18 on: December 23, 2005, 01:32:33 pm »
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).
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: A note about the Windows builds
« Reply #19 on: December 23, 2005, 02:28:51 pm »
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 :)
78 280Z, "a few bolt-ons" - [email protected]
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: A note about the Windows builds
« Reply #20 on: December 23, 2005, 02:52:07 pm »
Might be worth a consideration, if that doesn't break stuff.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: A note about the Windows builds
« Reply #21 on: December 23, 2005, 03:34:48 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. :)
78 280Z, "a few bolt-ons" - [email protected]
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
Re: A note about the Windows builds
« Reply #22 on: December 23, 2005, 07:58:44 pm »
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).

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: A note about the Windows builds
« Reply #23 on: December 23, 2005, 08:11:16 pm »
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.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
Re: A note about the Windows builds
« Reply #24 on: December 23, 2005, 08:29:46 pm »
 :(

Offline pjk

  • Multiple posting newcomer
  • *
  • Posts: 13
Re: A note about the Windows builds
« Reply #25 on: December 27, 2005, 01:03:22 am »
Can I bring this thread back to the build process
 Quote from tiwag December 22, 2005, 12:48:42 PM
Quote
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.
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.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).

Offline grv575

  • Official tester
  • Regular
  • ***
  • Posts: 381
Re: A note about the Windows builds
« Reply #26 on: December 27, 2005, 11:18:39 pm »
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).