Table of Contents
• Building CodeLite - Linux
You've decided to build a better Hello World program, so you've created a new workspace and added a project to it. Now you want to alter how CodeLite builds and runs that project...
Either click the appropriate button in the Workspace View toolbar, or right-click over the project's name in the Workspace View and, from the context menu, select Settings.... The 'Project Settings' dialog will appear, open at the 'General' tab.
At the top of the dialog you'll see the Configuration Type combobox, which will normally contain Debug or Release. To the right of that is a button that takes you to the Configuration Manager, where you can edit these choices and add others.
The 'General' tab lets you set various things, mostly to do with building the project. You can choose the Project Type: Executable, or static or dynamic library. You can select which Compiler will be used: g++, gcc (for 'C only' projects) and VC++; and the Debugger: currently the only choice is gdb.
Skipping a field for a moment, Intermediate Directory, which will probably be set either to ./Debug or ./Release, lets you configure where output files are put. If you don't like the default, there's a button to call a directory-select dialog, or you can write in an alternative. If you don't want to use an intermediate directory, enter '.'.
Next is Command, which is the filepath that CodeLite uses both to run and to debug the program. This will normally be ./<projectname>. In the field below you can add any Command Arguments to pass to the program as it's run e.g. --help will result in ./<projectname> --help. Finally, before running, the working directory will be changed to the contents of the Working Directory field.
When executing your program inside CodeLite, it actually runs in a terminal. The checkbox Pause when execution ends, which is ticked by default, means that the terminal stays open after closing the program; so any error messages or program output remains visible. If you don't need this, you can untick the box.
The 'Compiler' tab has three fields, each with a button for easier editing. Compiler Options lets you alter how wx-config is invoked. For example, if you want your project to build using a different wxWidgets version, you can change $(shell wx-config... to $(shell /path/to/desired/wx-config...
In Additional Search Path you tell the compiler to look for include files, should your project store them in unusual locations. Preprocessor lets you pass other macros (separated by semicolons) to the preprocessor; for example, you might have a logging macro to use in debug builds.
If you don't want to use the compiler for this project, for instance because it's written in PHP, tick the Compiler is not required for this project checkbox.
The 'Linker' tab is similar to the 'Compiler' tab. In Options you can alter the wx-config path, or set a different optimisation level. Library Path lets you add search paths, and Libraries libraries. (N.B. CodeLite will remove any 'lib' prefix from the library name and also any extension, so for g++ libMyLibrary.1.a will become -lMyLibrary.)
Make sure that you use the same wx-config path (and debug, unicode settings) as you did in the 'Compiler' tab.
The first field in the 'Debugger' tab lets you set a path to a particular debugger, in case you have several available. There is a checkbox and fields to allow debugging a remote target.
Lastly there is a field where you can enter commands to pass to the debugger on startup. For example, if there are several different versions of your source-code (perhaps for different wx builds, or different platforms) gdb may pick the wrong set of symbols to use. You can point it to the correct ones by entering the 'dir' command: dir /path/to/use/
If your platform doesn't need resources compiled e.g. Linux, tick the 'not needed' checkbox.
There are two fields, where you can alter the Compiler Options or add any Additional Search Paths to be passed to the Resource compiler during a build.
The 'PreBuild' and 'PostBuild' tabs are identical (except s/pre/post). Both allow you to define a collection of shell commands to be executed before (after) compilation. For example, you could add
wxrc /c /v /o resources.cpp resources.xrc
and it would be run before the actual build process starts.
Or on the PostBuild page you could add:
cp *.a ../../lib/ cp *.h ../../include/
The last tab, 'Custom makefile steps', also allows you to specify makefile rules to be executed during the pre-build stage. It's discussed in detail here.
Finally, at the bottom of the dialog is a 'Help' button. Instead of orthodox help, this lists available macros e.g. $(Date), $(WorkspacePath), which can be used in appropriate places inside the dialog.