CodeLite IDE

Hi Eran,

this is a bit peripheral to CL itself; I've been using CL on OSX to port a project to iOS, it worked great despite CL currently having no debugger on Mac... because Xcode's UI is a nightmare. The first time I tried linking project dependencies in Xcode it prompted me for makefiles, so I turned all my deps to makefiles, but then I couldn't find the same Xcode dialogs again, so was forced to shove all my sources in a single project... which worked in the iOS simulator... but I then noticed Xcode had COPIED my external source files instead of just referring to them so I'm ~ back to square one.

Do you have any tips to convert CL's project files to bypass Xcode's UI, say via make/cmake files or even XML parsing to regenerate Xcode files automatically or any kindof tip so one can spend most time inside CL & the least time possible in Xcode, with dynamic rewriting of Xcode projects the way cmake spews makefiles?

(*) edit: i.e. it'd be great if it was possible to dynamically generate an Xcode project from CL, then launch Xcode just to check compile- & runtime are ok, then get back to CL for further editing or debugging.

thx & cheers,

-- p

If you are using CMake for building, then I suggest that you build the latest CMake's master which has codelite's support. So you could enjoy both XCode and CodeLite

petah wrote:despite CL currently having no debugger on Mac...

Hmm, my gdb is working pretty well on Mac (gdb 6.3.5 but it still works...)

If gdb does not work for you within codelite make sure you don't have any startup commands that involves python in codelite's settings:
Settings => GDB settings => Startup Commands

Eran

eranif wrote:If you are using CMake for building, then I suggest that you build the latest CMake's master which has codelite's support. So you could enjoy both XCode and CodeLite

Ok. I'm not sure I'd "enjoy" Xcode either way, but minimize the pain it inflicts would be good enough

eranif wrote:

petah wrote:despite CL currently having no debugger on Mac...

Hmm, my gdb is working pretty well on Mac (gdb 6.3.5 but it still works...)

I understand Apple no longer supports GDB which now requires some workaround just to run on OSX. Without further info from CL's wiki I didn't feel the need to install it so far because I had very few porting bugs.

thx & cheers,

-- p

Seems like work could be done to support lldb... might not be too hard.

http://lldb.llvm.org/lldb-gdb.html

Not volunteering

I think it's best to wait til LLDB matures and some major distro starts using it, it does seem to be the future.

Eran - do you mind explaining how you combine Cmake & Xcode, maybe zip a sample Xcode project? Its UI just drives me nuts Worse is the fact you can't use environment variables, at least I haven't found how to expand them and end up specifying full disk paths

Btw is it just me or does the wiki not have a global table of content? I mean it has a TOC but it doesn't refer to all entries.

edit: just saw the wxWiki was updated http://wiki.wxwidgets.org/Creating_Xcod ... plications. Still, a cmake-based build would be nice so it's easy to switch between CL and Xcode...

thx & cheers,

-- p

Just spent an entire hour to build llvm/clang/lldb under Windows and I finally got a working lldb under Windows. Just to realize that I can't use it locally
I got a message from lldb mailing list stating that "there is no native window debugging support under Windows yet"
So supporting lldb will have to be Linux / OSX only

Whatever I did I got this result: Eran

Hi Eran,

do you have some LLDB binding beta that bleeding-edge users like myself can already toy with on Linux or is it still too unstable? Just being curious - no pressure

thx & cheers,

-- p

Not, really..

I am working on a small console app that tries to build and uses the LLDB API - for learning purposes (easier to study their code with a small console application)
Once, I will get the basics running - porting it to codelite will be a simple task

Eran