First of all thanks for this great IDE 8)
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 (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\ :D ) however it doesn't work. Any idea? is this a bug of wxWidgets or C::B?
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.
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
Quote- 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 :)
QuoteI 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.
QuoteCompiling 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,
QuoteQuoteCompiling 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.
Quote from: Alexis on July 07, 2008, 02:59:12 PM
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 !
Quote from: aurisc4 on July 08, 2008, 09:49:23 PM
QuoteQuoteCompiling 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 (http://wiki.codeblocks.org/index.php?title=Nightly_Cookbook#wxWidgets),
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.
Quote from: jens on July 08, 2008, 10:24:41 PM
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 :D
Search, learn and after ask on forums !
Quote from: jens on July 08, 2008, 10:24:41 PM
When I first compiled wxWidgets I used this entry of the nightly cookbook (http://wiki.codeblocks.org/index.php?title=Nightly_Cookbook#wxWidgets),
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.
Quote from: MortenMacFly on July 08, 2008, 10:44:07 PM
Quote from: jens on July 08, 2008, 10:24:41 PM
When I first compiled wxWidgets I used this entry of the nightly cookbook (http://wiki.codeblocks.org/index.php?title=Nightly_Cookbook#wxWidgets),
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 :D
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...
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...
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 :)
QuoteAnd 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.
QuoteSoon 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 :) )
Quote from: Alexis on July 09, 2008, 12:51:17 AM
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?
Quote from: Alexis on July 09, 2008, 12:51:17 AM
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 forumsTo 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
QuoteIf 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)...
QuoteFinally, 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...
QuoteYou 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...
QuoteIf 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 :D! And I think it deserves a link from wiki and main site, too.
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 (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 (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.
QuoteOk, 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,
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 8)
Quote from: Alexis on July 10, 2008, 03:06:20 PM
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...?! :?
QuoteI 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:
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:
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 warningsIt 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.
QuoteI would like peace in the world.
Peace with you, MortenMacFly.
QuoteI 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.
QuoteWell, 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.
QuoteAnyway, 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.
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 :)
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
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 :(
Here is the full log:
-------------- 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?
Quote from: inventore123 on July 11, 2008, 03:35:22 PM
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.
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
Quote from: inventore123 on July 11, 2008, 05:17:51 PM
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\MyLibinclude path:
$(#GV.base)\the_includeslib path:
$(#GV.base)\the_libs
I should hurry up and finish codepacks plugin :D