CodeLite IDE

Hi,
I'm beating on codelite (1.0.3034 on mswdws) some to support a new language ( cobra ).

I chose codeLite because it looked like it had some support for (editing) multiple languages ( and allowed extending support for that) and used a generic make based build system that was
configurable. I dont want/intend to get into hacking IDE src files and rebuilding unless theres no alternative (IDEs) to use and theres no other alternative.

Its gone reasonably well - got project support (unfortunately not via makefiles) and syntax coloring working but of course I have some questions .
- hope someone somewhere thinks they're worth of answering.

From the most general to the specific:

Generally where are you thinking of heading with IDE support for languages other than C/C++?
Do you anticipate codeLite to be a generally good base for an IDE supporting other langs as first class citizens or are you focussing mostly on C/C++
but allowing whatever can be supported with the use of the Scite Editor component and exposure of some of the config settings as config XML files ?
I'm thinking (over and above building) of such things as adding/exposing (Doccing) hooks for providing own language integration of such things as tags/cscope equivalents, completion,
builder wizards, ...

The current core build setup (through building and running a makefile) seems pretty well configurable for languages that have the traditional 2-3 stage build construction
(preprocess-> compile -> link: src -> src -> object -> executable), Unfortunately I couldnt get it to work that way (or find a way for it to work that way) for a
single step compile+link: srcs ->executable (which is what cobra does (cf c# and java)).
SFAICT this is mostly due to the internal build of the makefiles always making rules to turn srcfiles into objects then linking the .o's together.

Does codeLite have a way of configuring the built makefile like this already ??
That is a dependency rule for an executable on a single step compile srcs -> executable
e.g. ( If so I just couldnt find it).
If not is their any likelihood/interest of getting some s/w config knob to tell codeLite to make a 1 step srcs-to-executable rule in the makefile ( using $(CompilerTool) and associates)
rather than the current inbuilt 2 stage one?

I got the build to work using the Custom Build settings config but that relies on the language compiler being able to do any dependency checking which would be a reason for using
a makefile in the first place and it relies on some other mechanism to pass to the compiler its files build list to compile.
The cobra compiler fortunately has such a mechanism but it imposes some extra overhead on the IDE user to create and manage such a list (presumably duplicating what CodeLite is doing).
This seems to come down to not having a codeLite build macro ( like $(FileNamePath), $(FileName)) that provides a list of all the sourcefiles that the IDE has in its project
($(ProjectSourceFiles), $(SourceFiles), ...)
Is there such a macro already that I may have missed ?

Another possibility is ( since such a compiler can be considered a build tool in its own right) would be to allow a way of specifying a different ( non (gnu)make) build tool in the
SettingsMenu /BuildSettings -> Build Systems dialog. Unfortunately that doesnt work:
The only build system (saved) is gnu Makefile for g++/gnuc, you can override some of the settings used ( like the exact tool and switches ) in the dialog BUT the expansion of the CodeLite info passed to the build system execution is exactly oriented to (gnu) make and that doesnt seem to be configurable (either user or via XML/config file) ?

This causes two problems:
the first is that a -j <something> switch is always passed (even if you specify a 1 (or unlimited) for number of concurrent jobs) - I couldnt find a suppression mechanism for that
secondly it always passes a makefile name of (project_wsp.mk or somesuch ) and thats all - this is of little use for a build tool that wants a file list on the command line or as a build-list-file.

Is there some other way/somewhere else to specify the build System to use, thats not oriented around a make commandline syntax ?
If not is it possible/likely that the buildtool invocation could/can be modified to be allowed to be a little more generic
(e.g. dialog that allows config of a makefile invocation line (like now except you can suppress -j) plus an alternative that allows you to specify all of
build tool, switches, src file list to pass and a storage mechanism for such settings, or even a template in a user accessable XML file somewhere) ?

This could also be applicable to integration with other src consuming tools that arent buildtools ( e.g. interpreters ( for C anyway), prettyprinters, src analysers, policy checkers/enforcers, ....)

---
For the project Templates can you specify/add a new category for the project Template to reside in?
( I'd like to gang all the cobra language templates together rather than hanging them under User Templates).
I thought it might autodetect/create on a new category name but they were then ignored - Is there any way of doing that currently or are the categories hardwired somewhere ? (where?)

I've noticed in a couple of places you are expected to supply language specific things ( like filenames in file dialogs) the entries are constrained to allFiles or c/C++.
could that be configured specific to the language using or relaxed so can specify a wildcard glob pattern ( *.cobra ) ?
Would you be interested in a list of places where something similar is the case (wired to C/C++)?

In the Output View,Tasks tab how do you permanently configure the TODO/FIXME etc search patterns; with a cobra project nothing happens on pressing those buttons and the
configure button puts you in a find dialog that fills the FindResults tab ?

Naturally with supporting a non C++ language in a C++ focused IDE theres a whole lot of things that arent applicable - fortunately codeLite can be tweaked to suppress or hide those items (toolbars and plugins). Where does it store those settings to use on reload ?


Finally (for the moment anyway . I realise some of the above may come across as a bit negative, Its not intended so.
I was pleasantly surprised by how rapidly it was possible to support to a reasonable level a different language with a different build paradigm from C/C++ in codeLite,
I was unpleasantly surprised that it wasnt possible to do it in the (first two ) most obvious ways ( to me anyway) detailed above (makefile, buildtool).
Generally codeLite seems an excellent piece of software well oriented to C/C++ development - it just seems to me it has some curious (and small) blind spots wrt supporting additional
languages pretty seamlessly (buts its almost got it for much/most of the desirable capability).

(finally finally). Similarly to many Open source projects You need a whole lot more doc content on the website
using, configuring (my interest at the moment), Developing( building, code layout, content map,..).

When I get what I'm doing to some level of usefulness I'll be posting config and mod description to the cobra website
- would you like the same and perhaps a description of what I ended up doing to codeLite to support a different language (edit and builds) ??

Cheers

-- hops

Follow up Q.

IN codelite 1.0.35 if you have multiple projects in a workspace - how do you specify the build order of the projects when building a workspace ( Menu Build/Build Workspace)
or can they only be build in alpha order of the project names ??

hops wrote:IN codelite 1.0.35 if you have multiple projects in a workspace - how do you specify the build order of the projects when building a workspace ( Menu Build/Build Workspace)?

You just have to right clic on a project in the workspace tab. You will see a [Build order...] menu. This show the wanted window (select the build order).

ohhhhkay .. that does work go; to each project and specify its dependencies.

I'm pretty sure I would never have found that
- workspace build list is specified on each project
( though I suppose theres a weird sorta sense in hindsight)..

Thanks.

hops wrote:ohhhhkay .. that does work go; to each project and specify its dependencies

Its actually pretty object oriented - each object (project) encapsulates all the knowledge about itself

hops wrote:- workspace build list is specified on each project

This is where you are wrong.

This is the not "workspace build list" it is "project build list" - in codelite you are building projects not workspace - often one project is linked to another projects but there are cases where you want to build only part of the projects and not all of them.

Doing it the way you are suggesting, means that there is only one build order to build a set of projects.

The current implementation allows you to build part of the workspace projects without the need to build the entire workspace.

For example:
If in the workspace there are 3 projects: A B and C and the build order is:
A -> B -> C

If I would have set the build order in the workspace, I could build A->B->C however, in some cases (often I use it), I only want to build B (which involving building C as a prerequisite)
So, allowing to specify the build order for B and then building B will allow me to achieve this without the need to build 'A'

Its getting more complex as the number of projects you got in the workspace is getting bigger and bigger

Eran

Thats exactly right its not a workspace build list, its a per project dependency list
which happens to act to specify the workspace project build order which is why its not obviously discoverable if your focus is on workspace...

each object (project) encapsulates all the knowledge about itself

except the workspace doesnt ( encapsulate its build order - its built up from the set of projects dependencies)

in codelite you are building projects not workspace

I beg to differ; in codelite the menu item sez 'Build Workspace Crtl-Shift-B' so I'm working on the assumption that it actually does build (everything in ) the workspace
nothing about the 'build workspace' item affords to it being 'build project list' ( or perhaps more along your argument 'build all projects').
(the mechanism may be that of building projects but as soon as you are talking workspaces the area of focus has moved away/up from projects)

I understand your point that projects need dependency lists for flexibility in building projects individually.
My point is that the build workspace actions need a similar one (UI) exposed (for the workspace case alone) or the naming of the items need to change or
some other mechanism to lead the user to the per project dependency settings as the way of specifying the
'build workspace/build all projects' order of builds.

Whatever, this is the least of it.
-------------------------------------
Any possibility of replies to the queries in the original posting ??

Intentions/Directions/policy/ideas for allowing/supporting/providing support for languages other than c/c++ ?

Is there an existing way of specifying single stage build in codeLite generated makefile?
If not, interest/desire/intention in providing that capability ?

Is there an existing macro to provide list of all sourcefiles ( under codelite management in a project) ?
If not, interest/desire/intention to provide same ?

Possible to specify generic build system/wholly configurable commandline (from entries in buildSettings->buildSettingsDialog/Build Systems Tab)

How specify/provide new category for Project Template (Project Menu -> save as Template (project category)

Output View/Tasks Tab how do you permanently configure a (changed) TODO/FIXME etc search pattern; ( '# *TODO' vs default '/*[*]. *(TODO...')

Where does codelite store config settings hiding/disabling suppressed items (toolbars and plugins) ?
.

hops wrote:Intentions/Directions/policy/ideas for allowing/supporting/providing support for languages other than c/c++ ?

I dont plan to add support to other languages other than C/C++. I dont think that the current makefile allows single step building - you will need to write your own plugin for this to override the auto-generated makefiles - have a look at the QMakePlugin which overrides the auto-generated makefiles and generates its own makefile to be used for projects.

eranif wrote:Output View/Tasks Tab how do you permanently configure a (changed) TODO/FIXME etc search pattern; ( '# *TODO' vs default '/*[*]. *(TODO...')

Other than the current 4 hard-coded patterns, you cant (you could use the 'customize' button but like you noticed, it output it results into the 'Find In Files' tab) - please open a feature request for this and I will implement it

eranif wrote:Where does codelite store config settings hiding/disabling suppressed items (toolbars and plugins) ?

On Linux:
~/.codelite/config
On Windows:
C:\Program Files\CodeLite\config (assuming you installed codelite under C:\Program Files\CodeLite)

The files:
codelite.layout -> the GUI layout
codelite.xml -> the main configuration file for most of codelite configurations, such as: various state of buttons, menus, dialog positions/size and other
build_settings.xml -> all the compiler / build settings related
plugins.xml -> list of enabled/disabled plugins
debuggers.xml -> debugger related data / settings

It is safe to delete all these files, codelite will load the default settings.
Eran

OK THx re config settings

Tasks Tab: configure search patterns feature request added on Id:2903604

Any comments on these questions ?

Is there an existing macro ( like $(FileNamePath), $(CurrentFileName) to provide list of all of the sourcefiles ( under codelite management in a project) ?
Should I feature request this ?

Is it possible/likely to get the build systems processing totally genericised to allow specifying a generic build system via a wholly configurable commandline
( rather than current wired substitutions ? -j <jobs> and generated makefile name)
(from entries in buildSettings->buildSettingsDialog/Build Systems Tab).

How do you specify/provide a new category for a Project Template (Project Menu -> save as Template (project category) to reside in?
( I'd like to gang all the cobra language templates together rather than hanging them under User Templates).
I thought it might autodetect/create on a new category name but they were then ignored - Is there any way of doing that currently or are the categories hardwired somewhere ? (where?)

hops wrote:Is there an existing macro ( like $(FileNamePath), $(CurrentFileName) to provide list of all of the sourcefiles ( under codelite management in a project) ?
Should I feature request this ?

Yes, post a FR for this.

Also, please specify the format you are expecting (comma separated, space etc)

hops wrote:Is it possible/likely to get the build systems processing totally genericised to allow specifying a generic build system via a wholly configurable commandline
( rather than current wired substitutions ? -j <jobs> and generated makefile name)
(from entries in buildSettings->buildSettingsDialog/Build Systems Tab).

Not from the settings, currently -j is always specified

hops wrote:How do you specify/provide a new category for a Project Template (Project Menu -> save as Template (project category) to reside in?

It is currently hardcoded in the file: newprojectbasedlg.cpp (auto-generated file)

hops wrote:thought it might autodetect/create on a new category name but they were then ignored - Is there any way of doing that currently or are the categories hardwired somewhere ? (where?)

hard coded, if you need other, open a FR to allow adding user 'group'

Eran

Cool that was quick.

Feature requests coming up.

I dont plan to add support to other languages other than C/C++.

Fair enough -
How receptive/interested are you likely to be in bugs.feature requests that make it possible/easy to (fully) support other languages (than C/C++) in CodeLIte.
i.e things that would make it possible for anyone else interested to add support for a new/different languages (preferably with a minimum of coding and rebuild
needed) ?

Would you be interested in patches against the (latest) codebase for similar items ( assuming you cant be persuaded to treat them as valid bugs/features ) ?

Finally are you interested/want/would take additions for some support of additional languages (lexer and project files ??) to fold into future CodeLite releases ?