CL workspace to build/debug trunk CL?

[petah]

Is there a self-contained CodeLite workspace including source & projects for trunk CL, wx and plugins so that one can build&debug the next version of CL with CL itself, using only local paths and env vars so one's existing release CL and dependencies are unaffected?

Dunno if this has already been done or is doable at all but I think it'd encourage CL users to trace problems themselves, especially on platforms where switching libs like wx is dicey.

thx,

-- p

[eranif]

Is there a self-contained CodeLite workspace including source & projects for trunk CL, wx and plugins so that one can build&debug the next version of CL with CL itself, using only local paths and env vars so one's existing release CL and dependencies are unaffected?

You failed to provide your OS, but you should know that codelite is built and debugged using codelite itself

On, linux you simply needs to change the wx-config in order to build codelite with different wx library


For example, to build codelite with non-standard wx-config in debug mode + installing it elsewhere (so it wont conflict with the running version), you need to run configure like this:

Code: Select all

WXCONFIG=/path/to/my/wx-config ./configure --enable-pch --enable-debug --preifx=/path/to/installation/path

Then simply:

Code: Select all

make 
make install

codelite is built with -rpath specified in the linker stage + 'make install' copies the wx libraries to the installation directory so you can have multiple installations with multpile wx builds isntalled on the same machine without any problem

To debug newly installed codelite, open codelite and point the debugger to point to (project settings -> common -> program ro run / debug):
/path/to/installation/path/bin/codelite

The workspace that holds all codeilte sources is located under:
/path/to/codelite/sources/LiteEditor.workspace

Eran

[petah]

ok thx

[petah]

under Linux the CL workspace/project settings don't make sense (have Windows #defines, etc.), should one just use a custom build target pointing to the same Makefile once it's generated by cmake and ignore UI settings altogether?

Btw the root CMakeLists.txt mentions -DCMAKE_BUILD_TYPE=Release|Debug|FullDebug but I found no reference to FullDebug; is it used at all?

thx!

-- p

[eranif]

under Linux the CL workspace/project settings don't make sense (have Windows #defines, etc.), should one just use a custom build target pointing to the same Makefile once it's generated by cmake and ignore UI settings altogether?

Btw the root CMakeLists.txt mentions -DCMAKE_BUILD_TYPE=Release|Debug|FullDebug but I found no reference to FullDebug; is it used at all?

thx!

-- p

Usually, under linux you should compile using the command line as described here

If you wish to build codelite with codelite, then select the "Unix_Custom_Makefile" workspace settings.
Note that the targets there assumes that you have created the Makefiles under:
Debug:

Code: Select all

CODELITE_SRC/build-debug

Release

Code: Select all

CODELITE_SRC/build-release

Eran

[DavidGH]

Hi,

Btw the root CMakeLists.txt mentions -DCMAKE_BUILD_TYPE=Release|Debug|FullDebug but I found no reference to FullDebug; is it used at all?

I use it! According to this page it does '-O0 -g3', while Debug alone is '-O2 -g'.

Regards,

David

[petah]

If you wish to build codelite with codelite, then select the "Unix_Custom_Makefile" workspace settings.
Note that the targets there assumes that you have created the Makefiles under:
Debug:

Code: Select all

CODELITE_SRC/build-debug

Release

Code: Select all

CODELITE_SRC/build-release

Thx, with that setup & a few tweaks I can finally debug CL with CL.

BTW you may want to remove references to "./configure" in other LiteEditor.workspace settings (custom builds, I think) since the file no longer exists, that threw me off for a while

-- p

[pavel.iqx]

Could you share your tweaks or whole setup? May be publishing your workspace would be easiest?
I am also using linux and it would be significant help at start.

[petah]

My workspace settings won't do you any good because they're pretty much unchanged. If it sounds like a cop-out, like I thought when Eran first explained it to me, I can assure you it isn't. I can give you some hints I remember though.

The main challenge is keeping a clear head about which code you're debugging and which is static... it can get confusing because you're debugging CL with CL. In my case I even built the first one from cmd-line so I had 2 sets of source code and I also build my own wx flavour (I wasn't looking for trouble by hey).

You won't be using CL's usual UI-based compilation prefs but "pre-baked" makefiles, i.e. many of the UI panels won't have any relevance so you'll have to ignore them because changing them will have no effect. The "prebaked" make files depend on your particular env vars and directory layout so sharing them makes no sense either. Just make sure the pre-baked make files work from the command-line and they will from CL. Maybe delete some of the existing/default targets you won't use so yours stands out. I had one custom clean target and another custom make target which I had to manually select from a sub-menu by right-clicking on the project at each debug run but it's a minor annoyance; you just get used to it.

For a while I worried about the fact that the same CL prefs are used by both the "host" CL instance (debugger) and the CL "target" instance (debuggee), but nothing bad ever happened. If you're changing pref logic though I'd recommend you find a way so your target instance uses prefs in another location.

It's probably not the most efficient way but as far as I'm concerned once I can set breakpoints and step through my target CL I'm good. Eran will chime in with appropriate corrections.

cheers,

-- p

[pavel.iqx]

Thank you, I'll try it...