dirty file/project settings detection?

CodeLite installation/troubleshooting forum
petah
CodeLite Expert
Posts: 231
Joined: Sat Nov 24, 2012 8:04 pm
Genuine User: Yes
IDE Question: c++
Location: Los Angeles
Contact:

Re: dirty file/project settings detection?

Post by 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
main: Debian Jessie x64 + custom wxTrunk
User avatar
eranif
CodeLite Plugin
Posts: 6367
Joined: Wed Feb 06, 2008 9:29 pm
Genuine User: Yes
IDE Question: C++
Contact:

Re: dirty file/project settings detection?

Post by eranif »

petah wrote: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
Make sure you have read the HOW TO POST thread
petah
CodeLite Expert
Posts: 231
Joined: Sat Nov 24, 2012 8:04 pm
Genuine User: Yes
IDE Question: c++
Location: Los Angeles
Contact:

Re: dirty file/project settings detection?

Post by petah »

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

-- p
main: Debian Jessie x64 + custom wxTrunk
petah
CodeLite Expert
Posts: 231
Joined: Sat Nov 24, 2012 8:04 pm
Genuine User: Yes
IDE Question: c++
Location: Los Angeles
Contact:

Re: dirty file/project settings detection?

Post by 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
main: Debian Jessie x64 + custom wxTrunk
petah
CodeLite Expert
Posts: 231
Joined: Sat Nov 24, 2012 8:04 pm
Genuine User: Yes
IDE Question: c++
Location: Los Angeles
Contact:

Re: dirty file/project settings detection?

Post by 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
main: Debian Jessie x64 + custom wxTrunk
User avatar
eranif
CodeLite Plugin
Posts: 6367
Joined: Wed Feb 06, 2008 9:29 pm
Genuine User: Yes
IDE Question: C++
Contact:

Re: dirty file/project settings detection?

Post by 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
Make sure you have read the HOW TO POST thread
petah
CodeLite Expert
Posts: 231
Joined: Sat Nov 24, 2012 8:04 pm
Genuine User: Yes
IDE Question: c++
Location: Los Angeles
Contact:

Re: dirty file/project settings detection?

Post by 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
main: Debian Jessie x64 + custom wxTrunk
petah
CodeLite Expert
Posts: 231
Joined: Sat Nov 24, 2012 8:04 pm
Genuine User: Yes
IDE Question: c++
Location: Los Angeles
Contact:

Re: dirty file/project settings detection?

Post by petah »

CWD all good now, thx!

-- p
main: Debian Jessie x64 + custom wxTrunk
User avatar
eranif
CodeLite Plugin
Posts: 6367
Joined: Wed Feb 06, 2008 9:29 pm
Genuine User: Yes
IDE Question: C++
Contact:

Re: dirty file/project settings detection?

Post by 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
Make sure you have read the HOW TO POST thread
petah
CodeLite Expert
Posts: 231
Joined: Sat Nov 24, 2012 8:04 pm
Genuine User: Yes
IDE Question: c++
Location: Los Angeles
Contact:

Re: dirty file/project settings detection?

Post by petah »

Hi Eran,
eranif wrote: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
main: Debian Jessie x64 + custom wxTrunk
Post Reply