dirty file/project settings detection?

[petah]

Btw the rebuild-before-debugger bug, which you fixed, was most important. The CWD bug isn't all that critical because one can work around it in wxApp::OnInit() so if it's too much trouble please put it on the backburner.

thx again & cheers!

-- p

[eranif]

The CWD bug isn't all that critical because one can work around it in wxApp::OnInit() so if it's too much trouble please put it on the backburner.

Please give it a try with the latest git head ( I am on Windows atm, can't test this )

Eran

[petah]

I think it's working now but let me test on another system before jumping up & down brb.

-- p

[petah]

so it works if the project's working directory pref contains an absolute path, not if the WD is relative. The wx wizard project uses "./Debug" so LLDB starts and quits immediately:

Code: Select all

[ 21:14:16:521 DBG ] codelite-lldb: LLDB Thread: started
[ 21:14:16:611 DBG ] CODELITE>> LLDB started (normal)
[ 21:14:16:667 DBG ] codelite-lldb: running debugger. tty=(null)
[ 21:14:16:667 DBG ] codelite-lldb: target working directory is set to: ./Debug
[ 21:14:16:667 DBG ] codelite-lldb: Arguments are set to:
[ 21:14:16:667 DBG ] codelite-lldb: error while launching process. process launch failed: No such file or directory: ./Debug
[ 21:14:16:667 DBG ] codelite-lldb: NotifyExited called
[ 21:14:17:620 DBG ] codelite: ClearBreakpointDeletionQueue called
[ 21:14:17:620 DBG ] codelite: InvalidateBreakpoints called
[ 21:14:17:738 DBG ] CODELITE>> LLDB exited

EXE and WD paths are resolved correctly earlier in the log despite the failure though.

My other rather complicated projects (with clang and libc++) work fine because the project WD field is $(WorkspacePath) which resolves to an absolute path. I generally use CL env vars that resolve to absolute paths before invoking compiler/debugger so from my (selfish) perspective the bug is solved Let me know how I can help fixing other cases though...

thx again & cheers,

-- p

[petah]

* to be accurate the wx wizard's UI project uses:

Code: Select all

Intermediate Folder = ./Debug
Output File = $(IntermediateDirectory)/$(ProjectName)
Executable to Run / Debug = ./$(ProjectName)
Working Directory = $(IntermediateDirectory)

Replacing Intermediate Folder with '$(WorkspacePath)/Debug' or '$(ProjectPath)/Debug' no longer triggers an error.

-- p

[eranif]

Thats OK. These paths should be resolved by codelite before passed on to codelite-lldb...
Thats what happens when you code and don't test your code

I will do this once I will reboot my computer to Linux

Eran

[petah]

ok.

While we're on the subject of caching, CL creates and populates the (invisible) .codelite subdirectory with compilation.db. refactoring.db, etc. When two .workspace files sit in the same directory those files will get overwritten by whichever workspace is compiled last. Can any problems occur because both Workspaces will use the same files? Other files in the ..codelite dir are prefixed by the project name so there's no clash risk.

thx & cheers,

-- p

[petah]

CWD all good now, thx!

-- p

[eranif]

The compilation.db is used for clang code completion. It contains the compilation lines as seen by the compiler for instant access I keep this in a database, so in theory if your workspaces don't share files, then it should work just fine.

The refactoring db is used for instant 'find references' and rename symbol operations. So this may lead to false positive results...

Eran

[petah]

Hi Eran,

The compilation.db is used for clang code completion. It contains the compilation lines as seen by the compiler for instant access I keep this in a database, so in theory if your workspaces don't share files, then it should work just fine.

Unfortunately my main project is a client/server app so they share a lot of files (as many as possible:), ...like CodeLite and most modular projects guess The CL log shows many problems probably due to this conflict, hard to say for sure because log entries don't specify the originator project. Also the many CACHE CLEARED may just be a symptom of two background indexers from different workspaces taking turns trying to update the same file.

A pref specifying where build files should be created would fix it... or UUID index keys inside SQL dbs. When I built the wx wizard project to test your LLDB fixes the other day I created the project in my $HOME... which as expected wrote temp build files to .clang and .codelite... i.e. the user-wide ~/.codelite CL pref dir

If adding UI pref fields + documentation is too tedious I'd be happy with just a CL env var. I can't think of a strict user-side workaround; let me know if you do.

thx & cheers!

-- p