[Windows] precompiled wxWidgets in next release

[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.