Code::Blocks - User contributions [en]

Installing Code::Blocks from source on Gentoo

2006-11-18T05:22:04Z

Me22:

[[Category: Installing Code::Blocks]]
[[Category: Installing Code::Blocks from source]]
== Current Code::Blocks Compilation Methods for Gentoo ==

=== Subversion Portage Overlay ===
The current suggested method for emerging Code::Blocks is through the use of custom Ebuilds. The most prominently known portage overlay for the ebuilds is located here: [http://forums.gentoo.org/viewtopic-t-440412.html Gentoo Forums Code::Blocks Portage Overlay]

To create an overlay, please read [http://gentoo-wiki.com/HOWTO_Installing_3rd_Party_Ebuilds HOWTO Installing 3rd Party Ebuilds]

=== Create your own overlay ===
Another method of pulling together your own Ebuilds and creating your own portage overlay is to view the bug report for adding Code::Blocks to portage. [http://bugs.gentoo.org/show_bug.cgi?id=89533 Gentoo Code::Blocks Package Suggestion]

== Preparing Code::Blocks from Source (For 1.0rc2) ==

'''WORK IN PROGRESS'''

( Note: This is non-official and unverified. It worked for me, but... )

===Prepare Libraries===

Code::Blocks uses the wxWidgets (http://www.wxwindows.org/) library for its GUI. wxWidgets in turn uses GTK+ (http://www.gtk.org/). GTK+ is the library which GNOME desktop uses, but GNOME is not required to use it. In fact, odds are very good that if you have a number of GUI programs installed, you already have it. wxWidgets is also very common, if slightly less so.

You need to compile the wxGTK package with the following use flag:

+gtk2

The best way of getting this done is by adding a line to /etc/portage/package.use and recompiling wxGTK :

# echo x11-libs/wxGTK gtk2 >> /etc/portage/package.use
# emerge wxGTK

Note: Code::Blocks now works fine with Unicode. So you might want to build wxGTK with +unicode flag.

===Get the source code===

For this you have 2 options:

====Option 1: Download a source tarball.====

This is easy and means you have an easily-reproduced source set.

1) '''Download a source tarball''' from [http://sourceforge.net/project/showfiles.php?group_id=126998&package_id=142469 The Download Section of CodeBlocks.org]

2) '''Extract it'''. For this tutorial, I'm going to assume that you're installing as root, so /usr/local/src is a good pick. Any location is fine, however. This should create a codeblocks-1.0rc2 ( or similar ) folder.

====Option 2: Fetch from CVS====

This is not signifigantly harder and means you have a more up-to-date version of the source code. Usually this means more features and different bugs, which might be more or less annoying.

1) '''Install the CVS client'''. You might have it already. If not, this just requires the usual :
# emerge dev-util/cvs

2) '''Set the CVS root'''. Run the following command, and enter the password ''anonymous'' when asked :
# cvs -d :pserver:anonymous@cvs.sourceforge.net:/cvsroot/codeblocks login
Note that simply hitting enter--not entering a password--might also work.

3) '''Checkout a copy'''. cd to the directory you want the code to be placed in. Note that CVS will create a codeblocks directory for you. For this tutorial, I'm going to assume that you're installing as root, so /usr/local/src is a good pick. Any location is fine, however.
# cd /usr/local/src
The following command fetches the source from the CVS server :
# cvs -d :pserver:anonymous@cvs.sourceforge.net:/cvsroot/codeblocks checkout codeblocks

===Compile the Code===

1) '''cd to codeblocks directory'''. Following our example, from CVS this would be /usr/local/src/codeblocks; from a tarball, something like /usr/local/src/codeblocks-1.0rc2 :
# cd /usr/local/src/codeblocks
or
# cd /usr/local/src/codeblocks-1.0rc2

2) '''bootstrap'''. The very first time you unpack the source (or checkout from CVS), you need to run ./bootstrap. This will create a sane building environment.
# ./bootstrap
Note: If you get weird errors here try running following command and then bootstrap again.
# find . -type f -and -not -name "*.cpp" -and -not -name "*.h" -and -not -name "*.png" -and -not -name "*.bmp" | sed "s/.*/\"\\0\"/" | xargs dos2unix

3) '''configure'''. Use 'configure --help' to see what things you can enable or disable.
# ./configure

4) '''make and make install'''.
# make
# sudo make install

===More===

to come

To run Code::Blocks:
# codeblocks

===References===

[https://www.codeblocks.org/index.php?name=PNphpBB2&file=viewtopic&t=29 Linux releases or compiling on Linux] from the forum

[http://sourceforge.net/cvs/?group_id=126998 Code::Blocks : CVS access instructions]

[http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1 Basic Introduction to CVS and SourceForge.net (SF.net) Project CVS Services]

===Credits===

First version author: me22 ( me22.ca@gmail.com )
Some changes: sleipner ( themacgyver@gmail.com )
More updating: Crzysdrs

Installing Code::Blocks from source on Gentoo

2006-06-18T20:42:27Z

Me22:

[[Category:Installation\Build Instructions]]
'''Note: This Information is antiquated!'''

== The best way to compile C::B in gentoo these days is to use the codeblocks-svn ebuild which can be found in gentoo's bugzilla or in the forums ==

== Code::Blocks now works fine with Unicode and wx2.6, and the build system has changed ==

'''WORK IN PROGRESS'''

( Note: This is non-official and unverified. It worked for me, but... )

===Prepare Libraries===

Code::Blocks uses the wxWidgets (http://www.wxwindows.org/) library for its GUI. wxWidgets in turn uses GTK+ (http://www.gtk.org/). GTK+ is the library which GNOME desktop uses, but GNOME is not required to use it. In fact, odds are very good that if you have a number of GUI programs installed, you already have it. wxWidgets is also very common, if slightly less so.

You need to compile the wxGTK package with the following use flag:

+gtk2

The best way of getting this done is by adding a line to /etc/portage/package.use and recompiling wxGTK :

# echo x11-libs/wxGTK gtk2 >> /etc/portage/package.use
# emerge wxGTK

Note: Code::Blocks now works fine with Unicode. So you might want to build wxGTK with +unicode flag.

===Get the source code===

For this you have 2 options:

====Option 1: Download a source tarball.====

This is easy and means you have an easily-reproduced source set.

1) '''Download a source tarball''' from [http://sourceforge.net/project/showfiles.php?group_id=126998&package_id=142469 The Download Section of CodeBlocks.org]

2) '''Extract it'''. For this tutorial, I'm going to assume that you're installing as root, so /usr/local/src is a good pick. Any location is fine, however. This should create a codeblocks-1.0rc2 ( or similar ) folder.

====Option 2: Fetch from CVS====

This is not signifigantly harder and means you have a more up-to-date version of the source code. Usually this means more features and different bugs, which might be more or less annoying.

1) '''Install the CVS client'''. You might have it already. If not, this just requires the usual :
# emerge dev-util/cvs

2) '''Set the CVS root'''. Run the following command, and enter the password ''anonymous'' when asked :
# cvs -d :pserver:anonymous@cvs.sourceforge.net:/cvsroot/codeblocks login
Note that simply hitting enter--not entering a password--might also work.

3) '''Checkout a copy'''. cd to the directory you want the code to be placed in. Note that CVS will create a codeblocks directory for you. For this tutorial, I'm going to assume that you're installing as root, so /usr/local/src is a good pick. Any location is fine, however.
# cd /usr/local/src
The following command fetches the source from the CVS server :
# cvs -d :pserver:anonymous@cvs.sourceforge.net:/cvsroot/codeblocks checkout codeblocks

===Compile the Code===

1) '''cd to codeblocks directory'''. Following our example, from CVS this would be /usr/local/src/codeblocks; from a tarball, something like /usr/local/src/codeblocks-1.0rc2 :
# cd /usr/local/src/codeblocks
or
# cd /usr/local/src/codeblocks-1.0rc2

2) '''bootstrap'''. The very first time you unpack the source (or checkout from CVS), you need to run ./bootstrap. This will create a sane building environment.
# ./bootstrap
Note: If you get weird errors here try running following command and then bootstrap again.
# find . -type f -and -not -name "*.cpp" -and -not -name "*.h" -and -not -name "*.png" -and -not -name "*.bmp" | sed "s/.*/\"\\0\"/" | xargs dos2unix

3) '''configure'''. Use 'configure --help' to see what things you can enable or disable.
# ./configure

4) '''make and make install'''.
# make
# sudo make install

===More===

to come

To run Code::Blocks:
# codeblocks

===References===

[https://www.codeblocks.org/index.php?name=PNphpBB2&file=viewtopic&t=29 Linux releases or compiling on Linux] from the forum

[http://sourceforge.net/cvs/?group_id=126998 Code::Blocks : CVS access instructions]

[http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1 Basic Introduction to CVS and SourceForge.net (SF.net) Project CVS Services]

===Credits===

Original Author: me22 ( me22.ca@gmail.com )
Some changes: sleipner ( themacgyver@gmail.com )

Installing Code::Blocks from source on Gentoo

2005-10-25T19:43:48Z

Me22: OUT OF DATE

= NOTE: THIS INFORMATION IS ANTIQUATED! =

== Code::Blocks now works fine with Unicode and wx2.6, and the build system has changed ==

'''WORK IN PROGRESS'''

( Note: This is non-official and unverified. It worked for me, but... )

===Prepare Libraries===

Code::Blocks uses the [http://www.wxwindows.org/ wxWidgets] library for its GUI. wxWidgets in turn uses [http://www.gtk.org/ GTK+]. GTK+ is the library which GNOME desktop uses, but GNOME is not required to use it. In fact, odds are very good that if you have a number of GUI programs installed, you already have it. wxWidgets is also very common, if slightly less so. The trick with wxWidgets and Code::Blocks is that Code::Blocks can only use the gtk2, non-unicode version of wxWidgets

This means that you need to compile the wxGTK package with the following use flags settings:
+no_wxgtk1 +gtk2 -unicode
The best way of getting these set is by adding a line to /etc/portage/package.use and recompiling wxGTK :
# echo x11-libs/wxGTK no_wxgtk1 gtk2 -unicode >> /etc/portage/package.use
# emerge wxGTK

===Get the source code===

For this you have 2 options:

====Option 1: Download a source tarball.====

This is easy and means you have an easily-reproduced source set.

1) '''Download a source tarball''' from [https://www.codeblocks.org/modules.php?op=modload&name=Downloads&file=index&req=viewsdownload&sid=3 The Download Section of CodeBlocks.org]

2) '''Extract it'''. For this tutorial, I'm going to assume that you're installing as root, so /usr/local/src is a good pick. Any location is fine, however. This should create a CodeBlocks-1.0-beta5 ( or similar ) folder.

====Option 2: Fetch from CVS====

This is not signifigantly harder and means you have a more up-to-date version of the source code. Usually this means more features and different bugs, which might be more or less annoying.

1) '''Install the CVS client'''. You might have it already. If not, this just requires the usual :
# emerge dev-util/cvs

2) '''Set the CVS root'''. Run the following command, and enter the password ''anonymous'' when asked :
# cvs -d :pserver:anonymous@cvs.sourceforge.net:/cvsroot/codeblocks login
Note that simply hitting enter--not entering a password--might also work.

3) '''Checkout a copy'''. cd to the directory you want the code to be placed in. Note that CVS will create a codeblocks directory for you. For this tutorial, I'm going to assume that you're installing as root, so /usr/local/src is a good pick. Any location is fine, however.
# cd /usr/local/src
The following command fetches the source from the CVS server :
# cvs -d :pserver:anonymous@cvs.sourceforge.net:/cvsroot/codeblocks checkout codeblocks

===Compile the Code===

1) '''cd to the directory with the Makefile'''. Following our example, from CVS this would be /usr/local/src/codeblocks/src; from a tarball, something like /usr/local/src/CodeBlocks-1.0-beta5 :
# cd /usr/local/src/codeblocks/src
or
# cd /usr/local/src/CodeBlocks-1.0-beta5
If neither of those works, you can always use find to look for it :
# find <parent directory you extracted to> -name Makefile.unix

2) '''Build the sources'''. There's no configuration nessesary, just let make go to work :
# make -f Makefile.unix
# make -f Makefile.unix update
The first line does the actual compiling. The second moves the nessesary things to the output directory, zips some resources, and performs other miscellaneous nessesary tasks.

'''Note:''' The "update" script seems to be using Dos character encoding, which will result in its failure to run on Linux. To fix this, use dos2unix:
# emerge -av dos2unix
This will install dos2unix. Now we are ready to convert the script.
# dos2unix -n update update.unix
# chmod +x update.unix
# ./update.unix
The first line converts the script character encoding, the second makes it executable and the third runs it. This trick is from a forum post by ilkapo.

===More===

to come

For now ( assuming bash shell ):
$ cd /usr/local/src/codeblocks/src/output
$ LD_LIBRARY_PATH="." ./codeblocks.exe

===References===

[https://www.codeblocks.org/index.php?name=PNphpBB2&file=viewtopic&t=29 Linux releases or compiling on Linux] from the forum

[http://sourceforge.net/cvs/?group_id=126998 Code::Blocks : CVS access instructions]

[http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1 Basic Introduction to CVS and SourceForge.net (SF.net) Project CVS Services]

===Credits===

Original Author: me22 ( me22.ca@gmail.com )

Main Page

2005-09-06T00:53:43Z

Me22: /* Table of contents */

= Welcome to the official wiki site for Code::Blocks =
[https://www.codeblocks.org Code::Blocks] is an open-source, cross-platform IDE (Integrated Development Environment). Using a plugin architecture, its capabilities and features are defined by the provided plugins. Currently, [https://www.codeblocks.org Code::Blocks] is oriented towards C/C++. At the time of this writing, the following compilers are supported:
* [http://gcc.gnu.org/ GNU GCC] (Linux)
* [http://www.mingw.org MinGW GCC] (Win32)
* [http://msdn.microsoft.com/visualc/vctoolkit2003 Microsoft's Visual C++ Free Toolkit 2003] (Win32)
* [http://www.borland.com/products/downloads/download_cbuilder.html# Borland's C++ Compiler 5.5] (Win32)
* [http://www.digitalmars.com/ DigitalMars] (Win32)
* [http://store.scitechsoft.com/product_info.php?products_id=37/ OpenWatcom] (Win32)
* [http://sdcc.sourceforge.net/ Small Device C Compiler (SDCC)]

This site does not hold much information yet but, with the help of the [https://www.codeblocks.org Code::Blocks] users, we hope it will soon be filled with articles, tutorials, FAQs, etc.

== Table of contents ==
* [[Articles]]
* [[Tutorials]]
* [[Code::Blocks Interface]]
* [[FAQ]]
* [[Tips'n'Tricks]]

The [https://www.codeblocks.org/about.shtml Code::Blocks Team].

FAQ

2005-09-06T00:51:53Z

Me22: /* Is it possible to use Visual C++ 6.0 with Code::Blocks? */

= General =

== Is it possible to integrate the win32-help as in dev-cpp, to get help on the items under the caret? ==

Integration of the win32 API helpfile should be a no-brainer. Someone could just write a really simple plugin and, upon invocation (through a shortcut possibly), look at the word under the cursor and invoke windows help... If you think you 're up to the task, I can help you with all the info you need. If not, I could write it myself but no promises on a release date ;)

== Launching for the first time, Code::Blocks tells me I need to install GNU make. Is this necessary on a Windows system? ==

Since version 1.0-beta5, no it is not. Code::Blocks works with GNU "make" [http://www.mingw.org/download.shtml (here)] or without it (default). To choose the build method, go to "Project/Build options", switch to the "Other" tab and select the build method you prefer.

== What licence is Code::Blocks released under? ==

GNU General Public License 2 ([http://www.gnu.org/licenses/gpl.txt GPL])

= Compiling =

== What compiler can I use with Code::Blocks? ==

Code::Blocks philosophy is to be able to use any compiler on earth! Well, almost.

As a matter of fact it largely depends on the used compiler plugin. The one provided with the default Code::Blocks installation, supports GNU GCC (MinGW/Cygwin), MS Visual C++ Free Toolkit 2003, Borland's C++ Compiler 5.5 and DigitalMars Free Compiler.

== I imported a MSVCToolkit project/workspace, but Code::Blocks insists on trying to use GCC. What's wrong? ==

A little documentation problem ^^;. The "default compiler" is usually GCC, so when you imported it with "the default compiler", you told it to use GCC. To fix this situation, go to "Project", "Build Options" and select VC++ Toolkit as your compiler.

== I 'm using gcc compiler from an existing dev-cpp installation. How can I make it work? ==

''As of version 1.0-beta6, if a default MinGW installation is not detected, a Dev-C++ installation is checked for and is used if detected.''

You need to take two steps. First, set the compiler master path to the dev-cpp folder. It's under "Settings/Configure plugins/Compiler" in the "Programs" tab...
Second, you have to add two additional compiler (include) dirs. Go to "Settings/Configure plugins/Compiler" and in the "Compiler dirs" tab add "dev-cpp\include\c++" and "dev-cpp\include\c++\mingw32" (substituting "dev-cpp" with the actual dev-cpp installation folder).

== I just installed Code::Blocks Beta4 and I can't compile anything with BCC. ==

BCC is not supported 100% yet, unfortunately... The next release (namely 1.0-beta6) should address all BCC issues.

== My project should be compiled with a custom makefile. Is it possible with Code::Blocks? ==

Yes, as of version 1.0-beta4 it is supported. Go to project options and you 'll notice a "Custom Makefile" checkbox. If you check this, Code::Blocks will not create another Makefile for compiling but instead always use this Makefile. You have to understand, though, that it is your sole responsibility to keep this Makefile up to date.
Also make sure that "GNU make" is the selected build method for the specific compiler.

== I have downloaded MS VC++ Toolkit 2003 for a compiler. How do I tell Code::Blocks that it is my compiler? ==

Click on "Project/Build options" and select the compiler you want for your project/target.

== When compiling a wxWidgets project, I get several "variable 'vtable for xxxx' can't be auto-imported". What's wrong? ==

You need to add WXUSINGDLL in "Project->Build options->Compiler #defines" and rebuild your project (or create a new project and use the "Using wxWidgets DLL" project option which adds "-DWXUSINGDLL" to Project->Build options->Other options).
Other errors with the same resolution are:
'unresolved external symbol "char const * const wxEmptyString" (?wxEmptyString@@3PBDB)' or similar.
If you were using 1.0-finalbeta and were trying to build a statically linked wxWidgets project, the cause of the problem was some faulty templates. But that's fixed now.

== I can't compile a multithreaded app with VC Toolkit! Where are the libraries? ==

sorry, no fix for your problem...

Your problem doesn't come from CodeBlocks. It exists, because the free VC toolkit (VCTK) doesn't provide all the libraries and tools which are coming with Visual C++ (VC) which isn't free, unfortunately.

Try buying a full-fledged VC++, or even better, download MinGW :)

The libraries that can be obtained free of charge are:

Paths:
(VCT3) Visual C++ Toolkit 2003 - C:\Program Files\Microsoft Visual C++ Toolkit 2003\lib
(PSDK) Platform SDK - C:\Program Files\Microsoft Platform SDK\Lib
(NSDK) .NET 1.1 SDK - C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\lib

C runtime libs:
LIBC.LIB Single-threaded, static link (VCT3, NSDK)
LIBCMT.LIB Multithreaded, static link (VCT3, NSDK)
MSVCRT.LIB Multithreaded, dynamic link (import library for MSVCR71.DLL) (NSDK)
LIBCD.LIB Single-threaded, static link (debug) (VCT3, NSDK)
LIBCMTD.LIB Multithreaded, static link (debug) (NSDK)
MSVCRTD.LIB Multithreaded, dynamic link (import library for MSVCR71D.DLL) (debug) (NSDK)

C++ libs:
LIBCP.LIB Single-threaded, static link (VCT3, PSDK)
LIBCPMT.LIB Multithreaded, static link (VCT3)
MSVCPRT.LIB Multithreaded, dynamic link (import library for MSVCP71.dll) (none)
LIBCPD.LIB Single-threaded, static link (VCT3)
LIBCPMTD.LIB Multithreaded, static link (none)
MSVCPRTD.LIB Multithreaded, dynamic link (import library for MSVCP71D.DLL) (none)

Try setting the library linker directories to:
C:\Program Files\Microsoft Visual C++ Toolkit 2003\lib
C:\Program Files\Microsoft Platform SDK\Lib
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\lib
in that order.

The ones listed as (none) above are actually present in the IA64 and AMD64 subdirectories of the PSDK lib directory. Not sure if these would work on 32-bit windows, however, they may if they are
meant to work in 32-bit compatibility mode on the 64-bit processors. Worth a try. Otherwise, you
can link statically to the C++ library instead of using MSVCP71.dll. If you really want to link against MSVCP71.dll you can try to create MSVCP71.LIB from the dll using lib.exe and sed. Search google for "exports.sed" for detailed steps.

See also: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_c_run.2d.time_libraries.asp

== Where are the libraries for the OpenGL / SDL / etc. projects? ==

They're not bundled. The templates were provided for your convenience, but you need to download the libraries on your own.
In common terms, "batteries not included" :)

== Is it possible to use Visual C++ 6.0 with Code::Blocks? ==

As they say in ##C++ on FreeNode: 
cylon> msvc++6 is not a C++ compiler. It was made before the C++ standard, so it compiles some language that isn't C++. Upgrade.

Unicode Standards

2005-09-06T00:32:19Z

Me22:

This page is meant to be a location for developers to find all the current Unicode standards, or good practices, when editor and developing the Code::Blocks program. I am going to try and summarize the discussions that I was pointed to here, but I am leaving out the original author. Sorry Feel free to edit this to improve it, or keep it up to date. I am new to using wiki, so please exscuse the bad designs. This is a a '''VERY''' rough draft with no clear organizational pattern. ~ Joe M.

Actually, it's quite good. I did a quick read-through as it looks fine to me. All I did was add some things to the bottom. ~ me22

reference: [http://www.wxwidgets.org/manuals/2.4.2/wx458.htm#unicode]

== Macros ==
{NOTE: bullet list would look better here, but bold is used for now} 
'''__TFILE__''' = wxWidgets provide equivilant to __FILE__ 
'''__TDATE__''' = wxWidgets provide equivilant to __DATE__ 
'''__TTIME__''' = wxWidgets provide equivilant to __TIME__ 

'''_U()''' = Use it to convert non-literal char* strings to wxString. Use it for reading attributes from TiXmlNode's. If you deal with functions that return strings, you must use our _U macro. 

Code:
#ifdef wxUSE_UNICODE
#define _U(x) wxString((x),wxConvUTF8)
#define _UU(x,y) wxString((x),y)
#else
#define _U(x) (x)
#define _UU(x,y) (x)
#endif

i.e.:
Code:
const char* incompatible = "This is an incompatible string";
wxString compatible = _U(incompatible);

// wxString conftype = conf->Attribute("ConfigurationType"); // before
wxString conftype = _U(conf->Attribute("ConfigurationType")); // after :)

'''_C()''' = multibyte C string see wxhelp (wxMBConv classes overview)
Use this one for interacting with APIs needing char const*s, such as saving things to tinyXML.

Is defined in code as:
#if wxUSE_UNICODE
#define _UU(x,y) wxString((x),(y))
#define _CC(x,y) (x).mb_str((y))
#else
#define _UU(x,y) (x)
#define _CC(x,y) (x)
#endif

#define _U(x) _UU((x),wxConvUTF8)
#define _C(x) _CC((x),wxConvUTF8)

'''_wxT()''' = fixed text's - like XRC resources object names (only adds an L before the string (ONLY if you're in a unicode build).) 
wxT() is a macro which can be used with character and string literals (in other words, 'x' or "foo") to automatically convert them to Unicode in Unicode build configuration. Please see the Unicode overview for more information.

This macro is simply returns the value passed to it without changes in ASCII build. In fact, its definition is:

#ifdef UNICODE
#define wxT(x) L ## x
#else // !Unicode
#define wxT(x) x
#endif 

'''_T()''' = fixed text's - like XRC resources object names (only adds an L before the string (ONLY if you're in a unicode build).). 
This macro is exactly the same as wxT and is defined in wxWidgets simply because it may be more intuitive for Windows programmers as the standard Win32 headers also define it (as well as yet another name for the same macro which is _TEXT()).

Don't confuse this macro with _()! 
wxChar _T(char ch)

const wxChar * _T(const wxChar ch) 

'''_()''' = text's which might be translated to other user-languages 
This macro expands into a call to wxGetTranslation function, so it marks the message for the extraction by xgettext just as wxTRANSLATE does, but also returns the translation of the string for the current locale during execution.

Don't confuse this macro with _T()! 

'''wxPLURAL''' = This macro is identical to _() but for the plural variant of wxGetTranslation. 
const wxChar * wxPLURAL(const char *sing, const char *plur, size_tn) 

== Guidlines ==
'''char & wxChar:''' 
Do not use wxChar when is not a text character, because a wxChar in unicode is an int of 16 bits (not 8 bits):

Example for text:
wxChar im_a_character = _T('f');

Example for not text (not character):
char im_a_byte = 254;
but perhaps better would be to use:
byte im_a_byte = 254;
so it's clear that it's a byte and not a character.

'''Other:''' 
Problem code:
// indent code accordingly
wxString code = it->second;
code.Replace("\n", '\n' + lineIndent);

Solution:
<nowiki> If the input is a const char*, use "normal strings". If the input is a wxChar or wxString, use the _T("macros"). For example:</nowiki>

// indent code accordingly
wxString code = it->second;
code.Replace(_T("\n"), _T('\n') + lineIndent);

Some of the strings already converted in C::B, use _( when they should be _T(.

Example:

WRONG: wxXmlResource::Get()->LoadDialog(this, parent, _("dlgGenericMultiSelect"));

dlgGenericMultiSelect is a reference to a resource. Therefore it must use _T instead.

RIGHT: wxXmlResource::Get()->LoadDialog(this, parent, _T("dlgGenericMultiSelect"));

And don't forget to test for single characters, too!

All operations with wxStrings (not char*'s) should have _("string") for strings to be displayed to the user, and _T("string") for strings used internally.

Printf-like functions is - use c_str() (in examples in wxwidgets.org there are used different arguments for unicode and non-unicode versions where formating string was both "%s"). For example:

tmpkey.Printf(_T("%s/editor/keywords/%d"), key.c_str(), i);

'''XRCID and XRCCTRL macros:''' 
XRCID and XRCCTRL macros must _NOT_ be converted! They're pre-converted already!

WRONG: XRCCTRL(*this, _T("lblLabel"), wxStaticText)->SetLabel(label);

RIGHT: XRCCTRL(*this, "lblLabel", wxStaticText)->SetLabel(label);

'''concatenated strings:''' 
_() is macro which calls one of wxWidget's internal function so concatenating should look like this:

_("string 1" "string2" ... )

_T() macro simply adds 'L' before string given as a param (in Unicode of course, in normal mode it do nothing with the string) so concatenation should be:

_T("string1") _T("string2") ...

== Gotchas ==

'''_C() can return a proxy, not nessesarily a char const*'''

Don't write code like
Code:
char const * psz = _C( str ); // formerly str.mb_str(wxConvUTF8);

_C(), in unicode mode, returns a buffer, not a raw pointer. This is a good thing because the buffer's destructor takes care of freeing the memory used by the string. This buffer is implicitly convertible to a char const* so that it can be used in things like strlen( str.mb_str() ) immediatly, but that opens up the error I'm warning about in this post.

What actually happens in the above code? wxString::mb_str() returns a buffer object. Said buffer's implicit conversion to char const* is activated, and the result is stored in psz. The temporary buffer then GOES OUT OF SCOPE and ITS DESTRUCTOR DELETES THE MEMORY. It seems that windows doesn't care, but that linux often has already reused the memory by the time psz is used again in the code.

Solution:
Code:
wxWX2MBbuf psz = str.mb_str(wxConvUTF8);
wxWX2MBbuf takes ownership of the buffer ( no, it's not copied -- it's transfer of ownership semantics similar to std::auto_ptr ). That way you can actually use the memory until psz goes out of scope and deletes it.

'''Printf uses wxChars'''

When using wxString::Printf, %s wants wxChar const*, so just use .c_str(). This is important to watch out for because Printf uses varargs, which aren't typesafe, so the copmiler doesn't catch the error. If, for example, Mandrav uses .mb_str(), the compiler wont say anything because mb_str() is the same as c_str() in non-unicode mode, returning a char const*. However, when me22 runs it in Unicode mode, mb_str() returns a proxy ( see above ), which can't be passed through a vararg and the program crashes at runtime.

'''Streaming a plain char fails silently'''

This one was the source of the mysterious bug that replaced all the )'s in the class browser with 41's :P

Problem:
In unicode, the following compiles fine and doesn't crash:
my_stream << '\n';
However, my_stream traffics in wxChars, and '\n' is a plain char. This means that integer promotion is applied to '\n', so the effect is as if the code were:
my_stream << static_cast<int>('\n');
Which shows a number, instead of the character.

Solution:
Don't forget the _T()s!
Alternatively, use "\n" instead, which the compiler doesn't silently convert, so an easy-to-stop&fix compile error will occur.

This need to be rewritten. If nobody else improves on this, I will try and rewrite this once I have used these macros more. Joe M.

Unicode Standards

2005-09-05T23:27:06Z

Me22:

This page is meant to be a location for developers to find all the current Unicode standards, or good practices, when editor and developing the Code::Blocks program. I am going to try and summarize the discussions that I was pointed to here, but I am leaving out the original author. Sorry Feel free to edit this to improve it, or keep it up to date. I am new to using wiki, so please exscuse the bad designs. This is a a '''VERY''' rough draft with no clear organizational pattern. ~ Joe M.
Actually, it's quite good. I did a quick read-through as it looks fine to me. All I did was add some things to the bottom. ~ me22

reference: [http://www.wxwidgets.org/manuals/2.4.2/wx458.htm#unicode]

== Macros ==
{NOTE: bullet list would look better here, but bold is used for now} 
'''__TFILE__''' = wxWidgets provide equivilant to __FILE__ 
'''__TDATE__''' = wxWidgets provide equivilant to __DATE__ 
'''__TTIME__''' = wxWidgets provide equivilant to __TIME__ 

'''_U()''' = Use it to convert non-literal char* strings to wxString. Use it for reading attributes from TiXmlNode's. If you deal with functions that return strings, you must use our _U macro. 

Code:
#ifdef wxUSE_UNICODE
#define _U(x) wxString((x),wxConvUTF8)
#define _UU(x,y) wxString((x),y)
#else
#define _U(x) (x)
#define _UU(x,y) (x)
#endif

i.e.:
Code:
const char* incompatible = "This is an incompatible string";
wxString compatible = _U(incompatible);

// wxString conftype = conf->Attribute("ConfigurationType"); // before
wxString conftype = _U(conf->Attribute("ConfigurationType")); // after :)

'''_C()''' = multibyte C string see wxhelp (wxMBConv classes overview)
Use this one for interacting with APIs needing char const*s, such as saving things to tinyXML.

Is defined in code as:
#if wxUSE_UNICODE
#define _UU(x,y) wxString((x),(y))
#define _CC(x,y) (x).mb_str((y))
#else
#define _UU(x,y) (x)
#define _CC(x,y) (x)
#endif

#define _U(x) _UU((x),wxConvUTF8)
#define _C(x) _CC((x),wxConvUTF8)

'''_wxT()''' = fixed text's - like XRC resources object names (only adds an L before the string (ONLY if you're in a unicode build).) 
wxT() is a macro which can be used with character and string literals (in other words, 'x' or "foo") to automatically convert them to Unicode in Unicode build configuration. Please see the Unicode overview for more information.

This macro is simply returns the value passed to it without changes in ASCII build. In fact, its definition is:

#ifdef UNICODE
#define wxT(x) L ## x
#else // !Unicode
#define wxT(x) x
#endif 

'''_T()''' = fixed text's - like XRC resources object names (only adds an L before the string (ONLY if you're in a unicode build).). 
This macro is exactly the same as wxT and is defined in wxWidgets simply because it may be more intuitive for Windows programmers as the standard Win32 headers also define it (as well as yet another name for the same macro which is _TEXT()).

Don't confuse this macro with _()! 
wxChar _T(char ch)

const wxChar * _T(const wxChar ch) 

'''_()''' = text's which might be translated to other user-languages 
This macro expands into a call to wxGetTranslation function, so it marks the message for the extraction by xgettext just as wxTRANSLATE does, but also returns the translation of the string for the current locale during execution.

Don't confuse this macro with _T()! 

'''wxPLURAL''' = This macro is identical to _() but for the plural variant of wxGetTranslation. 
const wxChar * wxPLURAL(const char *sing, const char *plur, size_tn) 

== Guidlines ==
'''char & wxChar:''' 
Do not use wxChar when is not a text character, because a wxChar in unicode is an int of 16 bits (not 8 bits):

Example for text:
wxChar im_a_character = _T('f');

Example for not text (not character):
char im_a_byte = 254;
but perhaps better would be to use:
byte im_a_byte = 254;
so it's clear that it's a byte and not a character.

'''Other:''' 
Problem code:
// indent code accordingly
wxString code = it->second;
code.Replace("\n", '\n' + lineIndent);

Solution:
<nowiki> If the input is a const char*, use "normal strings". If the input is a wxChar or wxString, use the _T("macros"). For example:</nowiki>

// indent code accordingly
wxString code = it->second;
code.Replace(_T("\n"), _T('\n') + lineIndent);

Some of the strings already converted in C::B, use _( when they should be _T(.

Example:

WRONG: wxXmlResource::Get()->LoadDialog(this, parent, _("dlgGenericMultiSelect"));

dlgGenericMultiSelect is a reference to a resource. Therefore it must use _T instead.

RIGHT: wxXmlResource::Get()->LoadDialog(this, parent, _T("dlgGenericMultiSelect"));

And don't forget to test for single characters, too!

All operations with wxStrings (not char*'s) should have _("string") for strings to be displayed to the user, and _T("string") for strings used internally.

Printf-like functions is - use c_str() (in examples in wxwidgets.org there are used different arguments for unicode and non-unicode versions where formating string was both "%s"). For example:

tmpkey.Printf(_T("%s/editor/keywords/%d"), key.c_str(), i);

'''XRCID and XRCCTRL macros:''' 
XRCID and XRCCTRL macros must _NOT_ be converted! They're pre-converted already!

WRONG: XRCCTRL(*this, _T("lblLabel"), wxStaticText)->SetLabel(label);

RIGHT: XRCCTRL(*this, "lblLabel", wxStaticText)->SetLabel(label);

'''concatenated strings:''' 
_() is macro which calls one of wxWidget's internal function so concatenating should look like this:

_("string 1" "string2" ... )

_T() macro simply adds 'L' before string given as a param (in Unicode of course, in normal mode it do nothing with the string) so concatenation should be:

_T("string1") _T("string2") ...

== Gotchas ==

'''_C() can return a proxy, not nessesarily a char const*'''

Don't write code like
Code:
char const * psz = _C( str ); // formerly str.mb_str(wxConvUTF8);

_C(), in unicode mode, returns a buffer, not a raw pointer. This is a good thing because the buffer's destructor takes care of freeing the memory used by the string. This buffer is implicitly convertible to a char const* so that it can be used in things like strlen( str.mb_str() ) immediatly, but that opens up the error I'm warning about in this post.

What actually happens in the above code? wxString::mb_str() returns a buffer object. Said buffer's implicit conversion to char const* is activated, and the result is stored in psz. The temporary buffer then GOES OUT OF SCOPE and ITS DESTRUCTOR DELETES THE MEMORY. It seems that windows doesn't care, but that linux often has already reused the memory by the time psz is used again in the code.

Solution:
Code:
wxWX2MBbuf psz = str.mb_str(wxConvUTF8);
wxWX2MBbuf takes ownership of the buffer ( no, it's not copied -- it's transfer of ownership semantics similar to std::auto_ptr ). That way you can actually use the memory until psz goes out of scope and deletes it.

'''Printf uses wxChars'''

When using wxString::Printf, %s wants wxChar const*, so just use .c_str(). This is important to watch out for because Printf uses varargs, which aren't typesafe, so the copmiler doesn't catch the error. If, for example, Mandrav uses .mb_str(), the compiler wont say anything because mb_str() is the same as c_str() in non-unicode mode, returning a char const*. However, when me22 runs it in Unicode mode, mb_str() returns a proxy ( see above ), which can't be passed through a vararg and the program crashes at runtime.

'''Streaming a plain char fails silently'''

This one was the source of the mysterious bug that replaced all the )'s in the class browser with 41's :P

Problem:
In unicode, the following compiles fine and doesn't crash:
my_stream << '\n';
However, my_stream traffics in wxChars, and '\n' is a plain char. This means that integer promotion is applied to '\n', so the effect is as if the code were:
my_stream << static_cast<int>('\n');
Which shows a number, instead of the character.

Solution:
Don't forget the _T()s!
Alternatively, use "\n" instead, which the compiler doesn't silently convert, so an easy-to-stop&fix compile error will occur.

This need to be rewritten. If nobody else improves on this, I will try and rewrite this once I have used these macros more. Joe M.

Unicode Standards

2005-09-05T23:21:04Z

Me22:

This page is meant to be a location for developers to find all the current Unicode standards, or good practices, when editor and developing the Code::Blocks program. I am going to try and summarize the discussions that I was pointed to here, but I am leaving out the original author. Sorry Feel free to edit this to improve it, or keep it up to date. I am new to using wiki, so please exscuse the bad designs. This is a a '''VERY''' rough draft with no clear organizational pattern. 
<nowiki> -- Joe M.</nowiki>
Actually, it's quite good. I did a quick read-through as it looks fine to me. All I did was add some things to the bottom. ~ me22

reference: [http://www.wxwidgets.org/manuals/2.4.2/wx458.htm#unicode]

== Macros ==
{NOTE: bullet list would look better here, but bold is used for now} 
'''__TFILE__''' = wxWidgets provide equivilant to __FILE__ 
'''__TDATE__''' = wxWidgets provide equivilant to __DATE__ 
'''__TTIME__''' = wxWidgets provide equivilant to __TIME__ 

'''_U()''' = Use it to convert non-literal char* strings to wxString. Use it for reading attributes from TiXmlNode's. If you deal with functions that return strings, you must use our _U macro. 

Code:
#ifdef wxUSE_UNICODE
#define _U(x) wxString((x),wxConvUTF8)
#define _UU(x,y) wxString((x),y)
#else
#define _U(x) (x)
#define _UU(x,y) (x)
#endif

i.e.:
Code:
const char* incompatible = "This is an incompatible string";
wxString compatible = _U(incompatible);

// wxString conftype = conf->Attribute("ConfigurationType"); // before
wxString conftype = _U(conf->Attribute("ConfigurationType")); // after :)

'''_C()''' = multibyte C string see wxhelp (wxMBConv classes overview)
Use this one for interacting with APIs needing char const*s, such as saving things to tinyXML.

Is defined in code as:
#if wxUSE_UNICODE
#define _UU(x,y) wxString((x),(y))
#define _CC(x,y) (x).mb_str((y))
#else
#define _UU(x,y) (x)
#define _CC(x,y) (x)
#endif

#define _U(x) _UU((x),wxConvUTF8)
#define _C(x) _CC((x),wxConvUTF8)

'''_wxT()''' = fixed text's - like XRC resources object names (only adds an L before the string (ONLY if you're in a unicode build).) 
wxT() is a macro which can be used with character and string literals (in other words, 'x' or "foo") to automatically convert them to Unicode in Unicode build configuration. Please see the Unicode overview for more information.

This macro is simply returns the value passed to it without changes in ASCII build. In fact, its definition is:

#ifdef UNICODE
#define wxT(x) L ## x
#else // !Unicode
#define wxT(x) x
#endif 

'''_T()''' = fixed text's - like XRC resources object names (only adds an L before the string (ONLY if you're in a unicode build).). 
This macro is exactly the same as wxT and is defined in wxWidgets simply because it may be more intuitive for Windows programmers as the standard Win32 headers also define it (as well as yet another name for the same macro which is _TEXT()).

Don't confuse this macro with _()! 
wxChar _T(char ch)

const wxChar * _T(const wxChar ch) 

'''_()''' = text's which might be translated to other user-languages 
This macro expands into a call to wxGetTranslation function, so it marks the message for the extraction by xgettext just as wxTRANSLATE does, but also returns the translation of the string for the current locale during execution.

Don't confuse this macro with _T()! 

'''wxPLURAL''' = This macro is identical to _() but for the plural variant of wxGetTranslation. 
const wxChar * wxPLURAL(const char *sing, const char *plur, size_tn) 

== Guidlines ==
'''char & wxChar:''' 
Do not use wxChar when is not a text character, because a wxChar in unicode is an int of 16 bits (not 8 bits):

Example for text:
wxChar im_a_character = _T('f');

Example for not text (not character):
char im_a_byte = 254;
but perhaps better would be to use:
byte im_a_byte = 254;
so it's clear that it's a byte and not a character.

'''Other:''' 
Problem code:
// indent code accordingly
wxString code = it->second;
code.Replace("\n", '\n' + lineIndent);

Solution:
<nowiki> If the input is a const char*, use "normal strings". If the input is a wxChar or wxString, use the _T("macros"). For example:</nowiki>

// indent code accordingly
wxString code = it->second;
code.Replace(_T("\n"), _T('\n') + lineIndent);

Some of the strings already converted in C::B, use _( when they should be _T(.

Example:

WRONG: wxXmlResource::Get()->LoadDialog(this, parent, _("dlgGenericMultiSelect"));

dlgGenericMultiSelect is a reference to a resource. Therefore it must use _T instead.

RIGHT: wxXmlResource::Get()->LoadDialog(this, parent, _T("dlgGenericMultiSelect"));

And don't forget to test for single characters, too!

All operations with wxStrings (not char*'s) should have _("string") for strings to be displayed to the user, and _T("string") for strings used internally.

Printf-like functions is - use c_str() (in examples in wxwidgets.org there are used different arguments for unicode and non-unicode versions where formating string was both "%s"). For example:

tmpkey.Printf(_T("%s/editor/keywords/%d"), key.c_str(), i);

'''XRCID and XRCCTRL macros:''' 
XRCID and XRCCTRL macros must _NOT_ be converted! They're pre-converted already!

WRONG: XRCCTRL(*this, _T("lblLabel"), wxStaticText)->SetLabel(label);

RIGHT: XRCCTRL(*this, "lblLabel", wxStaticText)->SetLabel(label);

'''concatenated strings:''' 
_() is macro which calls one of wxWidget's internal function so concatenating should look like this:

_("string 1" "string2" ... )

_T() macro simply adds 'L' before string given as a param (in Unicode of course, in normal mode it do nothing with the string) so concatenation should be:

_T("string1") _T("string2") ...

== Gotchas ==

'''_C() can return a proxy, not nessesarily a char const*'''

Don't write code like
Code:
char const * psz = _C( str ); // formerly str.mb_str(wxConvUTF8);

_C(), in unicode mode, returns a buffer, not a raw pointer. This is a good thing because the buffer's destructor takes care of freeing the memory used by the string. This buffer is implicitly convertible to a char const* so that it can be used in things like strlen( str.mb_str() ) immediatly, but that opens up the error I'm warning about in this post.

What actually happens in the above code? wxString::mb_str() returns a buffer object. Said buffer's implicit conversion to char const* is activated, and the result is stored in psz. The temporary buffer then GOES OUT OF SCOPE and ITS DESTRUCTOR DELETES THE MEMORY. It seems that windows doesn't care, but that linux often has already reused the memory by the time psz is used again in the code.

Solution:
Code:
wxWX2MBbuf psz = str.mb_str(wxConvUTF8);
wxWX2MBbuf takes ownership of the buffer ( no, it's not copied -- it's transfer of ownership semantics similar to std::auto_ptr ). That way you can actually use the memory until psz goes out of scope and deletes it.

'''Printf uses wxChars'''

When using wxString::Printf, %s wants wxChar const*, so just use .c_str(). This is important to watch out for because Printf uses varargs, which aren't typesafe, so the copmiler doesn't catch the error. If, for example, Mandrav uses .mb_str(), the compiler wont say anything because mb_str() is the same as c_str() in non-unicode mode, returning a char const*. However, when me22 runs it in Unicode mode, mb_str() returns a proxy ( see above ), which can't be passed through a vararg and the program crashes at runtime.

This need to be rewritten. If nobody else improves on this, I will try and rewrite this once I have used these macros more. Joe M.

Tips'n'Tricks

2005-07-03T06:02:54Z

Me22: /* Personalities */

====[[Personalities]]====
====[[Fixing Internal Errors]]====

Installing Code::Blocks from source on Gentoo

2005-06-19T05:14:27Z

Me22: /* Option 2: Fetch from CVS */

'''WORK IN PROGRESS'''

( Note: This is non-official and unverified. It worked for me, but... )

===Prepare Libraries===

Code::Blocks uses the [http://www.wxwindows.org/ wxWidgets] library for its GUI. wxWidgets is turn uses [http://www.gtk.org/ GTK+]. GTK+ is the library the GNOME desktop uses, but GNOME is not required to use it. In fact, odds are very good that if you have a number of GUI programs installed, you already have it. wxWidgets is also very common, if slightly less so. The trick with wxWidgets and Code::Blocks is that Code::Blocks can only use the gtk2, non-unicode version of wxWidgets

This means that you need to compile the wxGTK package with the following use flags settings:
+no_wxgtk1 +gtk2 -unicode
The best way of getting these set is by adding a line to /etc/portage/package.use and recompiling wxGTK :
# echo x11-libs/wxGTK no_wxgtk1 gtk2 -unicode >> /etc/portage/package.use
# emerge wxGTK

===Get the source code===

For this you have 2 options:

====Option 1: Download a source tarball.====

This is easy and means you have an easily-reproduced source set.

1) '''Download a source tarball''' from [https://www.codeblocks.org/modules.php?op=modload&name=Downloads&file=index&req=viewsdownload&sid=3 The Download Section of CodeBlocks.org]

2) '''Extract it'''. For this tutorial, I'm going to assume that you're installing as root, so /usr/local/src is a good pick. Any location is fine, however. This should create a CodeBlocks-1.0-beta5 ( or similar ) folder.

====Option 2: Fetch from CVS====

This is not signifigantly harder and means you have a more up-to-date version of the source code. Usually this means more features and different bugs, which might be more or less annoying.

1) '''Install the CVS client'''. You might have it already. If not, this just requires the usual :
# emerge dev-util/cvs

2) '''Set the CVS root'''. Run the following command, and enter the password ''anonymous'' when asked :
# cvs -d :pserver:anonymous@cvs.sourceforge.net:/cvsroot/codeblocks login
Note that simply hitting enter--not entering a password--might also work.

3) '''Checkout a copy'''. cd to the directory you want the code to be placed in. Note that CVS will create a codeblocks directory for you. For this tutorial, I'm going to assume that you're installing as root, so /usr/local/src is a good pick. Any location is fine, however.
# cd /usr/local/src
The following command fetches the source from the CVS server :
# cvs -d :pserver:anonymous@cvs.sourceforge.net:/cvsroot/codeblocks checkout codeblocks

===Compile the Code===

1) '''cd to the directory with the Makefile'''. Following our example, from CVS this would be /usr/local/src/codeblocks/src; from a tarball, something like /usr/local/src/CodeBlocks-1.0-beta5 :
# cd /usr/local/src/codeblocks/src
or
# cd /usr/local/src/CodeBlocks-1.0-beta5
If neither of those works, you can always use find to look for it :
# find <parent directory you extracted to> -name Makefile.unix

2) '''Build the sources'''. There's no configuration nessesary, just let make go to work :
# make -f Makefile.unix
# make -f Makefile.unix update
The first line does the actual compiling. The second moves the nessesary things to the output directory, zips some resources, and performs other miscellaneous nessesary tasks.

'''Note:''' The "update" script seems to be using Dos character encoding, which will result in its failure to run on Linux. To fix this, use dos2unix:
# emerge -av dos2unix
This will install dos2unix. Now we are ready to convert the script.
# dos2unix -n update update.unix
# chmod +x update.unix
# ./update.unix
The first line converts the script character encoding, the second makes it executable and the third runs it. This trick is from a forum post by ilkapo.

===More===

to come

For now ( assuming bash shell ):
$ cd /usr/local/src/codeblocks/src/output
$ LD_LIBRARY_PATH="." ./codeblocks.exe

===References===

[https://www.codeblocks.org/index.php?name=PNphpBB2&file=viewtopic&t=29 Linux releases or compiling on Linux] from the forum

[http://sourceforge.net/cvs/?group_id=126998 Code::Blocks : CVS access instructions]

[http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1 Basic Introduction to CVS and SourceForge.net (SF.net) Project CVS Services]

===Credits===

Original Author: me22 ( me22.ca@gmail.com )

Main Page

2005-03-15T23:18:52Z

Me22: /* Welcome to the official wiki site for Code::Blocks */

= Welcome to the official wiki site for Code::Blocks =
[https://www.codeblocks.org Code::Blocks] is an open-source, cross-platform IDE (Integrated Development Environment). Using a plugin architecture, its capabilities and features are defined by the provided plugins. Currently, [https://www.codeblocks.org Code::Blocks] is oriented towards C/C++. At the time of this writing, five (5) major C/C++ compilers are supported:
* [http://gcc.gnu.org/ GNU GCC] (Linux)
* [http://www.mingw.org MinGW GCC] (Win32)
* [http://msdn.microsoft.com/visualc/vctoolkit2003 Microsoft's Visual C++ Free Toolkit 2003] (Win32)
* [http://www.borland.com/products/downloads/download_cbuilder.html# Borland's C++ Compiler 5.5] (Win32)
* [http://www.digitalmars.com/ DigitalMars] (Win32)

This site does not hold much information yet but, with the help of the [https://www.codeblocks.org Code::Blocks] users, we hope it will soon be filled with articles, tutorials, FAQs, etc.

== Table of contents ==
* [[Articles]]
* [[Tutorials]]
* [[FAQ]]
* [[Tips'n'Tricks]]

The [https://www.codeblocks.org Code::Blocks] Team.

Installing Code::Blocks from source on Gentoo

2005-03-15T23:10:13Z

Me22:

'''WORK IN PROGRESS'''

( Note: This is non-official and unverified. It worked for me, but... )

===Prepare Libraries===

Code::Blocks uses the [http://www.wxwindows.org/ wxWidgets] library for its GUI. wxWidgets is turn uses [http://www.gtk.org/ GTK+]. GTK+ is the library the GNOME desktop uses, but GNOME is not required to use it. In fact, odds are very good that if you have a number of GUI programs installed, you already have it. wxWidgets is also very common, if slightly less so. The trick with wxWidgets and Code::Blocks is that Code::Blocks can only use the gtk2, non-unicode version of wxWidgets

This means that you need to compile the wxGTK package with the following use flags settings:
+no_wxgtk1 +gtk2 -unicode
The best way of getting these set is by adding a line to /etc/portage/package.use and recompiling wxGTK :
# echo x11-libs/wxGTK no_wxgtk1 gtk2 -unicode >> /etc/portage/package.use
# emerge wxGTK

===Get the source code===

For this you have 2 options:

====Option 1: Download a source tarball.====

This is easy and means you have an easily-reproduced source set.

1) '''Download a source tarball''' from [https://www.codeblocks.org/modules.php?op=modload&name=Downloads&file=index&req=viewsdownload&sid=3 The Download Section of CodeBlocks.org]

2) '''Extract it'''. For this tutorial, I'm going to assume that you're installing as root, so /usr/local/src is a good pick. Any location is fine, however. This should create a CodeBlocks-1.0-beta5 ( or similar ) folder.

====Option 2: Fetch from CVS====

This is not signifigantly harder and means you have a more up-to-date version of the source code. Usually this means more features and different bugs, which might be more or less annoying.

1) '''Install the CVS client'''. You might have it already. If not, this just requires the usual :
# emerge dev-util/cvs

2) '''Set the CVS root'''. Run the following command, and enter the password ''anonymous'' when asked :
# cvs -d :pserver:anonymous@cvs.sourceforge.net:/cvsroot/codeblocks login

3) '''Checkout a copy'''. cd to the directory you want the code to be placed in. Note that CVS will create a codeblocks directory for you. For this tutorial, I'm going to assume that you're installing as root, so /usr/local/src is a good pick. Any location is fine, however.
# cd /usr/local/src
The following command fetches the source from the CVS server :
# cvs -d :pserver:anonymous@cvs.sourceforge.net:/cvsroot/codeblocks checkout codeblocks

===Compile the Code===

1) '''cd to the directory with the Makefile'''. From CVS this will be <?>; from a tarball, <?> :
# cd <?>
or
# cd <?>

2) '''Build the sources'''. There's no configuration nessesary, just let make go to work :
# make -f Makefile.unix
# make -f Makefile.unix update
The first line does the actual compiling. The second moves the nessesary things to the output directory, zips some resources, and performs other miscellaneous nessesary tasks.

===More===

to come

===References===

[https://www.codeblocks.org/index.php?name=PNphpBB2&file=viewtopic&t=29 Linux releases or compiling on Linux] from the forum

[http://sourceforge.net/cvs/?group_id=126998 Code::Blocks : CVS access instructions]

[http://sourceforge.net/docman/display_doc.php?docid=14033&group_id=1 Basic Introduction to CVS and SourceForge.net (SF.net) Project CVS Services]

===Credits===

Original Author: me22 ( me22.ca@gmail.com )