Cleaning everthing of Code::blocks out of the system

[azagaros]

How do I clean code::blocks completely out so I can do a fresh complete install?

Something isn't letting things compile correctly.  It is confusing libraries between compilers.

I am also trying to get the wxWidgets 2.9.1 to work with this program with all the correct found libraries.

This program scanned the computer for the installed compilers I thought when I installed it the first time..  How do I make it do that again, so it sets itself up correctly? 

Everything I have tried to get an application's sources to compile has been fighting something and it doesn't matter which compiler.  I currently have OpenWatcom 1.9, BCC 5.3, and Mingw from the Mingw downloader.

this is getting on my nerves and would like some help to point me in the right direction.

[Jenna]

C::B configuration is stored in %APPDATA%\codeblocks\default.conf on windows and in ~/.codeblocks/default.conf on linux.
Just remove (or rename) the file if C::B is not running and it wil be recreated from scratch if you start C::B the next time, but all user settings are lost.

Alternatively (and normally the better option) to reset the compilers is to go to "Settings -> Compiler and debugger... -> Global compiler settings -> [your compiler] -> Toolchain executables" and check the settings.
You can also try the "Auto-detect" button to find the compiler if it is in its standard installation part.
You can (of course) also click "Reset defaults" to reset the compilers settings to the defaults.

[azagaros]

%APPDATA% doesn't give me enough info for where this garbage is.   Searching for it has not turned it up with an exact file name.

when it confused openWatcom with Gcc switches, which were set up by the C::B and not me, was frustrating to clean up.  It would handle bcc and openwatcom just fine for general c++ and not anything with libraries specific to each compiler.  wxWidgets can be compiled by each of the compilers and as a result with different libraries with each of them.  C::B doesn't manage this too well.  Especially when you can used different compilers between the global default and the local build setting for the app.   Its a headache to to switch between compilers, which needs to be easier.

I tried everything with in C::B first and it didn't clean up the mess.  Including uninstalling it and fighting with it again and again to no avail. 

[pirx67]

%APPDATA% doesn't give me enough info for where this garbage is.   Searching for it has not turned it up with an exact file name.

On your Windows Desktop click Start->run and then enter "cmd.exe" and confirm with enter. This will open a terminal window with a command interpreter. There enter "echo %APPDATA%". This should print the application data directory path for the user that is currently logged in (you).

In this directory you should find the Code::Blocks configuration files mentioned by Jens. Please be aware that the application data folder is a hidden directory normally NOT displayed by the Windows Explorer.

For the problem to use different compilers / libraries to build an executable from one common set of source files I guess one way to accomplish it would be to setup one workspace "wsp_myprojects" with multiple projects each having one compiler selected like "prj_myproject_gcc", "prj_myproject_icc" and so on.

Then you could right click the project name i. e. "prj_myproject_icc" in the context menu select "Build options ...". In the resulting dialog box you select in the left column your project name again (to change release and debug build together) and select then the appropriate compiler for this project.

Then you will have multiple projects with different compiler configurations. Then import all the source files you need for the build in the different projects.

YMMV.

Disclaimer:
    I've not tested it.

pirx67

PS.: Try first to compile your project with one of the installed compilers and get it running.
Some hints on this are here in the FAQ http://wiki.codeblocks.org/index.php?title=FAQ#Q:_How_do_I_troubleshoot_an_compiler_problem.3F.