Author Topic: A note about the Windows builds  (Read 25933 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
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
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" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

takeshimiya

  • Guest
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."

takeshimiya

  • Guest
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.

takeshimiya

  • Guest
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
#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."

takeshimiya

  • Guest
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
#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" - 12.71@109.04
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
		<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
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
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" - 12.71@109.04
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 !