[Windows] precompiled wxWidgets in next release

[inventore123]

First of all thanks for this great IDE 

I think the Windows release is great, but installing wxWidgets is somewhat complicated. The wxPack is good, but *huge*, it takes up more than 2 GBytes... the wxMsw is smaller, but compiling it is a bit difficult and takes time...
It would be great if the next release come with wxWidgets precompiles as well as MinGw.

Therefore I made a precompiled version of wxWidgets (based on wxMsw) that you can download here http://www.webalice.it/fede.tft/codeblocks/wxWidgets-2.8-%28Compiled%29.zip. It has the following advantages:

- It comes with a Readme.txt that explains how it has been compiled, how to install it, and how to test if it has been installed correctly.
- It is *small*, the zip file is less than 10MB, and once extracted it is only 40MB
- It is compiled as static library, so the .exe files don't require any .dll

I have 3 questions:
1) Is there a chance that this or another precompiled version of wx will be included in the next release?
2) (This seems to be a C::B bug) when I try to make a new project, it does not compile because it does not link by default with libwxjpej.a and libwxtiff.a, but after adding those libs to Project>Build Options>Release>Linker Settings>Link Libraries everything works fine.
3) When compiling wxMsw the folder must be in a path without spaces, but in theory oce compiled there should be no problem in moving the folder to a location with spaces (for example C:\Program files\CodeBlocks\  ) however it doesn't work. Any idea? is this a bug of wxWidgets or C::B?

[killerbot]

we do offer the wx dll though. You can download it from the nightly build, and it is included in the official release. We do however do NOT distribute wxWidgets.

[dje]

Well, it is nice BUT
- MinGW is one of the 15 C::B supported compilers
- You provide one of the 16 wxWidgets configurations (BUILD=release/debug SHARED=0/1 MONOLITHIC=0/1 UNICODE=1/1)

I think it is too specific, it is a nice contrib if people use your configuration, you may provide a link to it in the wiki.
Compiling wxWidgets is not so complicated...

Dje

[inventore123]

- MinGW is one of the 15 C::B supported compilers

It is true, but there are 2 version of wxwidgets for Windows one with mingw and one without it, just include a precompiled wx only in the mingw release

I think it is too specific

You're right about that, maybe i can compile it in those options:
static, non monolithic, unicode (release & debug)
dll, monolithic, unicode (release & debug)

This is a total of 4 builds. Or if you have a better combination, let me know.

[Alexis]

Compiling wxWidgets is not so complicated...

It's easy when... you know (as I do). For a newbie, it's difficult. Think about beginners !

Just imagine: you're a beginner and you install a full-bundled Code::Blocks. Then you create a project with the wizard, you compile/link, and your exe starts ! Everything would be so easy and straightforward !
Just look at the number of people in this forum that try to compile wxWidgets, or install C::B and don't know how to link their exe based on wx. Some of them are discouraged and don't go farther.

That's why I think C::B should be released as two "bundles" :
- a single bundle : C::B only (not wuth even MinGW under Windows)
- a full bundle : C::B + MingGW + wxWidgets (the 4 configurations already described)

I think that shipping a full-bundled Code::Blocks would do a lot for promoting wxWidgets and C::B.

Kind regards,

[aurisc4]

Compiling wxWidgets is not so complicated...

It's easy when... you know (as I do). For a newbie, it's difficult. Think about beginners !

Yes, when I first compiled wx, I succeeded in 5th or 7th time and it definately didn't seem to be easy.

[dje]

Think about beginners !

Just imagine: you're a beginner and you install a full-bundled Code::Blocks. Then you create a project with the wizard, you compile/link, and your exe starts ! Everything would be so easy and straightforward !
Just look at the number of people in this forum that try to compile wxWidgets, or install C::B and don't know how to link their exe based on wx. Some of them are discouraged and don't go farther.

So nice ! Just avoid people thinking ! Solve problems for them, that way they will progress and learn !

[Jenna]

Compiling wxWidgets is not so complicated...

It's easy when... you know (as I do). For a newbie, it's difficult. Think about beginners !

Yes, when I first compiled wx, I succeeded in 5th or 7th time and it definately didn't seem to be easy.

When I first compiled wxWidgets I used this entry of the nightly cookbook,
and it succeeded the first time.

I think that in the most cases it does not work because the user thinks he can do it without reading the doc's.
And it's almost always good to know what you do before you start.
People have to learn that reading documentation is one of the most important things if you want to work efficiently with any SDK.
Or you get frustrated because nothing works as expected and you spend much time in trying out things, that work in a much easier way if you know how.

[dje]

I think that in the most cases it does not work because the user thinks he can do it without reading the doc's.
And it's almost always good to know what you do before you start.
People have to learn that reading documentation is one of the most important things if you want to work efficiently with any SDK.
Or you get frustrated because nothing works as expected and you spend much time in trying out things, that work in a much easier way if you know how.

My hero 
Search, learn and after ask on forums !

[MortenMacFly]

When I first compiled wxWidgets I used this entry of the nightly cookbook,
and it succeeded the first time.

Amen.

My opinion:
We won't do anyones homework here. If you ever want to develop with wxWidgets (this includes development for C::B) you *really* should be able to at least compile wxWidgets. Literally millions of people (it's a wide spreaded toolkit) did it and succeeded with the so-much-important lessons learned. There is tons of help around but of course one needs to 1.) read, 2.) think and finally 3.) understand. It's so easy!

This of course includes me. I did it the first time as Jens said and succeeded, too.

[dje]

When I first compiled wxWidgets I used this entry of the nightly cookbook,
and it succeeded the first time.

Amen.

My opinion:
We won't do anyones homework here. If you ever want to develop with wxWidgets (this includes development for C::B) you *really* should be able to at least compile wxWidgets. Literally millions of people (it's a wide spreaded toolkit) did it and succeeded with the so-much-important lessons learned. There is tons of help around but of course one needs to 1.) read, 2.) think and finally 3.) understand. It's so easy!

This of course includes me. I did it the first time as Jens said and succeeded, too.

Amen too 

[Alexis]

Never heard of learning curve ? Compiling wxWidgets is not the funniest part of developping...
wxWidgets is so huge and complex (yet not complicated !) that it will let user think !

You may use Gentoo (i. e. compile yourself Linux). It's one of the best ways understand Linux. But, as a matter of fact, most people prefer Ubuntu ! It's less intimidating...

[dje]

Learning curve ? Yes !
That does not mean constant 0 "curves" !

And by the way, building wxWidgets is not so complicated, there are lots of documents/threads that explian how or solve most of the problems BUT you have to search, read and learn...

[inventore123]

My opinion:
A developer doesn't even need an IDE to write code. All he/she needs is a text editor and a shell to call the compiler. And by doing that there are many things to learn (for example, how to write a makefile). Nevertheless an IDE makes coding simpler, easier, and faster.
It's the same for a precompiled library. You will learn much by compiling it yourself (as I'm doing it now), but it's easier and faster to use a precompiled one.

Soon I'll post the new version of wx precompiled, with the above 4 configurations. Once it has been posted, do what you want with it: add to the next C::B release, post a link in the wiki, or just do nothing 

[Alexis]

And by the way, building wxWidgets is not so complicated

And no so easy either...
Just read the testimony of aurisc4, above in this thread.

Well, guys, it's not a technical issue, it's a "marketing" issue.
I'm afraid there is here the infamous Linux syndrom [which I thought was declining] : Read the f***g manual (even for matters not easy for newbies).
But as you don't care of this stuff, I give up.

[Alexis]

Soon I'll post the new version of wx precompiled, with the above 4 configurations. Once it has been posted, do what you want with it: add to the next C::B release, post a link in the wiki, or just do nothing

Good news ! Thanks a lot (acting for beginners  )

[mandrav]

Well, guys, it's not a technical issue, it's a "marketing" issue.
I'm afraid there is here the infamous Linux syndrom [which I thought was declining] : Read the f***g manual (even for matters not easy for newbies).
But as you don't care of this stuff, I give up.

I think you 're mixing some things up here.

If we provide pre-built wx libs then why shouldn't we provide qt libs too? And boost? And whatever else?
You have to understand that this is out of this project's scope. We provide the tool (C::B) and as much documentation as is possible for us to write/maintain (considering this is an open-source project and people do work on it on their free time). We also provide support for the project through these very forums. Support that is relevant to our tool (as opposed to doing the homework of users).

So, you want to use wx but can't build it for whatever reason? Use wxPack.
wxPack is too big for you? We 're sorry but we won't build wx for you too.
If inventore123 (or anyone else) is willing to pre-compile and provide wx libs (or any other lib) for others to use, they 're of course free to do so and can also "advertise" it in these forums so others become aware.

Finally, did it ever occur to you that the wx team itself does NOT provide windows binaries of their own product?

[dje]

I'm afraid there is here the infamous Linux syndrom [which I thought was declining] : Read the f***g manual (even for matters not easy for newbies).
But as you don't care of this stuff, I give up.

You forgot Read the f***g wiki and Search the f***g forums
To my mind, People use too early the forums. There should be preliminary steps such as 'What did you read before posting' and 'What did you try before posting'.

Dje

[Alexis]

If we provide pre-built wx libs then why shouldn't we provide qt libs too? And boost? And whatever else?

Because C::B is based upon wx and because C::B embeds wxSmith (a RAD tool for wx)...

Finally, did it ever occur to you that the wx team itself does NOT provide windows binaries of their own product?

Dit it ever occur to you that wxDevCpp is an integrated tool providing wx Windows binaries ?
It's an endless debate...

You have to understand that this is out of this project's scope. We provide the tool (C::B) and as much documentation as is possible for us to write/maintain (considering this is an open-source project and people do work on it on their free time). We also provide support for the project through these very forums. Support that is relevant to our tool

Well, this a reason I admit much better than: "User has to cope him/herself with wx compilation and it's very nice for him/her since it's an excellent way to learn wx". You want to focus on core activity (developping C::B) and not get involved into something peripheral. It's true time is limited...

If inventore123 (or anyone else) is willing to pre-copile and provide wx libs (or any other lib) for others to use, they 're of course free to do so and can also "advertise" it in these forums so others become aware.

OK. I'm happy  ! And I think it deserves a link from wiki and main site, too.

[inventore123]

Ok, here are the precompiled versions:
I made two versions, because the full release is quite big.
These are specifically made for C::B, and include a Readme.txt with installation instructions.
It's the last version of wx: 2.8.8

1) DLL version: release & debug
compiled in MONOLITHIC and UNICODE mode.
File size 20MB, once extracted 120MB http://inventore.acme-x.net/wxWidgets-2.8-%28dll+release+debug%29.tar.bz2

2) DLL + static: both release & debug
compiled in MONOLITHIC and UNICODE mode.
File size 90MB, once extracted 510MB http://inventore.acme-x.net/wxWidgets-2.8-%28static+dll+debug+release%29.tar.bz2
This is quite big because the static debug libwxmsw2.8ud.a file is 370MB !
Anyway it is still much smaller than wxPack.

[Alexis]

Ok, here are the precompiled versions:

Good job !

But I would also have done the following :

• Create a setup.exe
• Add Code::Blocks and MingGW in the setup
• During installation set the path in C::B directly (see in readme.txt, second step of INSTALL)

You would thus have something very straightforward (excellent for beginners!), like what you can see in wxDevCpp.

Regards,

[inventore123]

Well, I think there's still a problem:
to make the installation cleaner, it would be better to move the wx folder inside C::B's folder like MinGW.
However, if you move wx folder in a path that contains spaces, like
"C:\Program files\Codeblocks" it no longer works.

It's true that wxWidgets won't compile in a path with spaces, but once compiled should no longer have problems, instead it still doesn't work 
I made a test with a makefile project and it did work even in a path with spaces, so it seems it's a bug of C::B

Any idea how to solve the bug? If someone can find a solution it would be possible to make a "Codeblocks" folder with all the IDE files and folders, plus two subfolders: "MinGW" and "wxWidgets". Once we have that, it would be easy to pack everything in a Setup.exe, perfect for beginners.
It would even be posible to install it on a USB key 

[MortenMacFly]

But I would also have done the following :

I would like peace in the world.

I really can't believe you say so... why don't you do what you want yourself? You make me feel like a slave. Anything else you want us to do...?! :?

[inventore123]

I really can't believe you say so...

Well, I dont't know who Alexis is, but to me it does not seem to be a noob that wants other to do his homework. It seems another one, like me, that was surprised in finding that the release of C::B included wxSmith, but not wxWidgets, and thinks that a 'plug and play' release will attract more users to this good IDE.

Anyway, can someone explain me why, if I move the wx folder in "C:\Program files\Codeblocks" (a path with one space), I can't compile anything? Here are the errors:
Build messages:

Code

wx/msw/wx.rc: No such file or directory
can't open icon file `wx/msw/std.ico': Invalid argument
preprocessing failed.
=== Build finished: 3 errors, 0 warnings ===

Build log:

Code

Compiling: resource.rc
C:\DOCUME~1\fede\MYDOCU~1\CODEBL~1\dll_test\resource.rc:3:24: wx/msw/wx.rc: No such file or directory
gcc: Files\CodeBlocks\wxWidgets-2.8.8\include: No such file or directory
gcc: Files\CodeBlocks\wxWidgets-2.8.8\lib\gcc_dll\mswu: No such file or directory
windres.exe: can't open icon file `wx/msw/std.ico': Invalid argument
windres.exe: preprocessing failed.
Process terminated with status 1 (0 minutes, 0 seconds)
3 errors, 0 warnings

It looks like the path "C:\Program Files\CodeBlocks\wxWidgets-2.8.8\include" becomes for some reason
"Files\CodeBlocks\wxWidgets-2.8.8\include". I'm using C::B 8.02 on win XP.

[Alexis]

I would like peace in the world.

Peace with you, MortenMacFly.

I really can't believe you say so... why don't you do what you want yourself ? You make me feel like a slave. Anything else you want us to do...?!

I'm afraid you don't get the point. I've been knowing how to setup my wx/CB environment on WinXP and Linux for a while.
What is doing inventore123 is useless for me. But will be very useful for noobs.
I think his project is a very good idea and I'm only giving my suggestions to make it better. I'm busy on other projects and I haven't the time to do it myself.

Well, I dont't know who Alexis is, but to me it does not seem to be a noob that wants other to do his homework. It seems another one, like me, that was surprised in finding that the release of C::B included wxSmith, but not wxWidgets, and thinks that a 'plug and play' release will attract more users to this good IDE.

EXACTLY ! This is exactly my situation.

Anyway, can someone explain me why, if I move the wx folder in "C:\Program files\Codeblocks" (a path with one space), I can't compile anything? Here are the errors:

inventore123, what is your toolchain, and where is it installed ?
I am using C::B 5010 on WinXP SP2. The install directory is C:\Program Files\CodeBlocks.
The toolchain is MinGW-5.1.3. It is installed in C:\MinGW. Everything works well for me.

[inventore123]

I'm using C::B 8.02 (Official release that includes MinGW)
The IDE is installed in "C:\Program files\CodeBlocks"
MinGW is installed in "C:\Program files\CodeBlocks\MinGW"
now, if i put wxWidgets directory in "C:\wxWidgets-2.8.8" everything works fine (And this is what I wrote in Readme.txt)

BUT if I move the wx directory in "C:\Program files\CodeBlocks\wxWidgets-2.8.8" I cannot compile anything from C::B (but if I try to compile a project from the command line, with a Makefile, it works. So it seems a C::B bug)

Moving the wx directory inside C::B's directory will make the installation cleaner, centralizing all data in one folder, and I think is necessary before wrapping everything in a setup.exe

Alexis, where have you installed wx?
Any help is appreciated 

[stahta01]

What version of MinGW windres?
It may have problems with spaces or C::B might not be passing the command to it right.

windres --version

I suggest turning on full compiler logging and looking at the command.

Tim S

[inventore123]

Code

windres --version
GNU windres (GNU binutils) 2.18.50.20080109
Copyright 2007 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.

 I'll try to enable full logging to see if it is a bug of C::B or MinGW.

Anyway, I've spotted another bug: I can't specify a relative path for the #wx global variable 
It would be very esasy to put the wxWidgets' folder inside CodeBlocks folder and just use "./wxWidgets-2.8.8" as path. But if I do it C::B outputs *many* error lines about not finding wx's .h files 

[inventore123]

Here is the full log:

Code

-------------- Build: Debug in dll_test ---------------

mingw32-g++.exe -pipe -mthreads -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE  -Wall  -g -D__WXDEBUG__    -I"C:\Program Files\CodeBlocks\wxWidgets-2.8.8\include" -I"C:\Program Files\CodeBlocks\wxWidgets-2.8.8\contrib\include" -I"C:\Program Files\CodeBlocks\wxWidgets-2.8.8\lib\gcc_dll\mswud"  -c "C:\Documents and Settings\fede\My Documents\codeblocks\dll_test\dll_testMain.cpp" -o obj\Debug\dll_testMain.o
windres.exe -i C:\DOCUME~1\fede\MYDOCU~1\CODEBL~1\dll_test\resource.rc -J rc -o obj\Debug\resource.res -O coff -I"C:\Program Files\CodeBlocks\wxWidgets-2.8.8\include" -I"C:\Program Files\CodeBlocks\wxWidgets-2.8.8\lib\gcc_dll\mswud" 
C:\DOCUME~1\fede\MYDOCU~1\CODEBL~1\dll_test\resource.rc:3:24: wx/msw/wx.rc: No such file or directory
gcc: Files\CodeBlocks\wxWidgets-2.8.8\include: No such file or directory
gcc: Files\CodeBlocks\wxWidgets-2.8.8\lib\gcc_dll\mswud: No such file or directory
windres.exe: preprocessing failed.
Process terminated with status 1 (0 minutes, 1 seconds)
2 errors, 0 warnings

The problem of spaces in wx path seems NOT a bug of C::B, but a bug of windres.exe, because C::B correctly surround the path with "".
Ok, now that we know where the bug is, any suggestion about what to do?

also any suggestion about why relative path don't work?

[MortenMacFly]

The problem of spaces in wx path seems NOT a bug of C::B, but a bug of windres.exe, because C::B correctly surround the path with "".

That is true. You now have 2 options:
1.) Use a later version of windres (binutils) but then other things might get broken.
2.) Define the path to wx as 8.3 type (short path name). You can seti up accordingly in your project options or (if it is coming from a global variable) within this setup.

[inventore123]

Thanks!
The 8.3 trick worked, I changed "C:\Program files\CodeBlocks\wxWidgets-2.8.8" in "C:\PROGRA~1\CodeBlocks\wxWidgets-2.8.8", and now I can compile everything.
I'll also try with new MinGW releases, to see if new windres.exe no longer have this bug.

Last thing, can you confirm me that the path for #wx global variable MUST be an absolute path, and that relative path don't work (I mean relative with respect to codeblocks folder, like saying "./wxWidgets-2.8.8" instead of "C:\Program files\CodeBlocks\wxWidgets-2.8.8"), because when I do so I get errors not only related to windres.exe, but also gcc.exe

[MortenMacFly]

Last thing, can you confirm me that the path for #wx global variable MUST be an absolute path

That's true. Hence for the "childs" (like include etc...) you can use relative path's again - just like a recursion. This way you need to change only one path if you are on another platform.

For example, imagine a global variable, named "GV":
base path: C:\Whatever\MyLib
include path: $(#GV.base)\the_includes
lib path: $(#GV.base)\the_libs

[JGM]

I should hurry up and finish codepacks plugin