CodeLite IDE

Howdy,

I'm trying to set up some code in CodeLite for a new project. I come from a *nix background, so I'm used to having everything piled into a couple of directories, with Makefiles sorting out the details.

I understand that with IDE's this isn't the right approach. Instead, I think there's supposed to be a single "built" item (lib, dll, exe, jar) per CodeLite "project".

I've tried to follow this approach, but frankly I'm finding it tedious to maintain all the various settings of path, environment, compiler, linker, etc. that have to be updated.

So I'm guessing that I'm doing something wrong.

I am trying to construct a bunch of outputs:

- shared librarys (dll/so)
- executables
- test suites (unittest++ executables linked with my dlls, etc.)

The source is C++, with some generated files produced by Ragel and Bison.

I'm using the MinGW/Msys toolset. I'm also using some third-party libraries (e.g., boost, icu) that aren't part of my project.

I definitely need to use precompiled headers - all those templates!

My intention is (presently) to have a single workspace that is dedicated to all this stuff.

Given the above, I'd love to hear what the "best practice" is for setting this up in CodeLite?

Some (but not all) of my specific questions are below. These are the ones that occurred to me right off, and I probably didn't ask the right ones since I don't know all the ins and outs of CodeLite yet. So if you have some advice (or links), please share it.

- Is there a "msys mode" for CodeLite on Windows?
I use Msys+Mingw and so it's a bit of a shock to have to put D:\Devel\... paths into the Environment Settings. But then those same settings "poison" the generated .mk files, so I can't run them in gnu make under msys. Is there some way to get codelite to not run C:\windows\system32\cmd.exe to kick off all the subprocesses?

- how do I handle the external components?
I tried creating a custom "Environment Settings" for this project, and setting, e.g., $(BOOST_DIR) in there. Is there a better way to tell CL about external headers, paths, and libraries?

- how do I deal with my output DLLs?
I understand that they need to be in the same directory as the programs when running, so who should do the copying (for test programs, e.g.), or should all the projects share a single workspace-wide output directory (per configuration)?

- how do I structure the source to handle generated source code (from Ragel & Bison)?
I originally thought to emit the generated code in the output directory, but apparently CodeLite won't build the files if they aren't added to the project, so I think now they should go in the source dirs. But what about generated header files?

- how do I set up include files?
I was inclined to create a separate $(ProjectFOO)/include/FOO/ directory inside each project FOO, so that I could compile with -I "$(ProjectFOO)/include" and then write #include "FOO/header" in my source. But with precompiled headers and generated headers, I am wondering if I should compile with -I "$(workspace)" and have a big bag of code laying in the project dirs (with #include "ProjectFOO/header" in the source files)? Alternatively, should I export my headers as some kind of post-build thing?

- How much code goes into a project?
I was thinking of one project=one dll, but I think that it's possible to compose libraries into a dll. So if I have a subsystem that could be a library, should I just leave it in the dll project under a subdir(s) for source and headers, or should I split it off into a lib project and then link that into the dll?

- How do I handle unit tests?
If I try to test a DLL, do I copy it into the output dir of the test program's project? Do I move all this stuff to a workspace output dir? Do I run the tests as a post-build step of the test project?

- Is there any way to make bulk changes to all of the projects?
For example, if they're all going to have to link against a particular boost library, can I change that library or add a new library across all projects?

Thanks in advance for any help,

=Austin

Austin Hastings wrote:- Is there a "msys mode" for CodeLite on Windows?
I use Msys+Mingw and so it's a bit of a shock to have to put D:\Devel\... paths into the Environment Settings. But then those same settings "poison" the generated .mk files, so I can't run them in gnu make under msys. Is there some way to get codelite to not run C:\windows\system32\cmd.exe to kick off all the subprocesses?

codelite is built to work with native Windows and not under any third party shell environment (e.g. msys/cygwin) - if you are using the default build system (i.e. allowing codelite to generate the makefiles) it will always use the cmd.exe, you can set up 'Custom Build', in that case, codelite will run exactly what it was told

Austin Hastings wrote:- how do I handle the external components?
I tried creating a custom "Environment Settings" for this project, and setting, e.g., $(BOOST_DIR) in there. Is there a better way to tell CL about external headers, paths, and libraries?

Add what you need to the project settings. (linker/compiler tabs)

Austin Hastings wrote:- how do I deal with my output DLLs?
I understand that they need to be in the same directory as the programs when running, so who should do the copying (for test programs, e.g.), or should all the projects share a single workspace-wide output directory (per configuration)?

Depends on the tree structure you are using. Usually, I simply change the output of the DLL project to place itself in the bin directory (project settings of the DLL project, and change the 'Output File' field to point to something like ../bin/MyDLl.dll (ofc, change to path to suite your needs)

You can always set up a 'post-build' command (again, in the 'project settings -> Pre / Post build commands')

Austin Hastings wrote:- how do I set up include files?
I was inclined to create a separate $(ProjectFOO)/include/FOO/ directory inside each project FOO, so that I could compile with -I "$(ProjectFOO)/include" and then write #include "FOO/header" in my source. But with precompiled headers and generated headers, I am wondering if I should compile with -I "$(workspace)" and have a big bag of code laying in the project dirs (with #include "ProjectFOO/header" in the source files)? Alternatively, should I export my headers as some kind of post-build thing?

Just set up the path in the project settings. copying the headers in 'post build' is not a good idea (creates duplicate entries on disk, which might confuse some people)

Austin Hastings wrote:- How do I handle unit tests?
If I try to test a DLL, do I copy it into the output dir of the test program's project? Do I move all this stuff to a workspace output dir? Do I run the tests as a post-build step of the test project?

Usually, the best approach is to run the unit testing as part of the build (post build). Just make sure you generate the DLL into the bin directory along with the test program so there is no need to copy anything

Austin Hastings wrote:- Is there any way to make bulk changes to all of the projects?
For example, if they're all going to have to link against a particular boost library, can I change that library or add a new library across all projects?

Not atm. You could however add permanent include / lib path to a compiler (from the menu: Settings | Build Settings | Compilers | < You compiler > | Advanced)

Eran

Hi Austin,

To take the tedium out of setting all of the project "settings" I clone my own templates.
Have a look at your install directory codelite\templates\projects. I clone one of these by making a copy and then editing the xml as required.
Now when you create a new project it will be all set up and ready to go. Just need to add the files.
I have been using this technique successfully for my embedded projects.

Don't be afraid to experiment a little.

Thank you Eran for this great feature.

Cheers,

Noel Diviney.