dirty file/project settings detection?

[petah]

hey,

is the logic triggering recompilation of dirty/modified source files handled "manually" by CL or is it delegated to make? If it's handled by CL does it use only the file system's modification timestamps or are there additional checks like total size, head/tail block checksums?

Should one take special precautions with a pre-build step with a $(MAKE) to ensure its cache will get flushed on modification?

I ask because it seems that recently I had to force-rebuild workspaces more often than usual, but it could be due to my source control (Perforce) fudging the file modification stamps.

thx & cheers,

-- p

ps: thx for the lua plugin forum

[eranif]

It is handled by make.
codelite uses gcc's -MT switch to generate dependencies target (the *.o.d files)
If you need to force rebuilds, then I think your guess is correct - it has to do with your source control tool
Eran

[petah]

Hi Eran,

I finally figured out what's going on, which is partially my fault.

At least on Gtk/x64 (*), Cl has a bug regarding project files that have been excluded; when you run a project with an edited file -- and enabled always build before debugging -- CL will rebuild the project but willl include all project source files, even those that had been excluded. The problem doesn't happen if you compile manually, but effectively prevents one from using the 'always build' option if you're used to just edit & run.

I recently had to port code so had platform-specific project configurations and files I'd exclude on other builds, but because they'd still get included on 'always builds' and triggered compiler errors (compiling on a platform they shouldn't be), I had disabled the 'always build' option and wouldn't realize when I just hit run after an edit that it was executing a stale binary.

The UI also doesn't properly reflect which files are excluded but that's a minor issue. If I wasn't so tied up right now I'd look for the fixes myself (yeah yeah you heard that before )... which I'll do if the bugs are still outstanding by the time I'm freed-up.

Anyway I'm relieved the problem isn't related to make's caching nor my source control!

thx & cheers,

-- p

(*) with trunk CL built with trunk wx from 2 days ago

[eranif]

Hi Petah,

Can you please provide a sample workspace on how to reproduce this behavior?

Thanks
Eran

[petah]

I'm not sure this is the best example cause it depends on OpenGL, it's just what I happen to be working on now. This assumes you have enabled always build before debugging. Really you should be able to reproduce it with any project that has excluded project files like:

<File Name="src/main.cpp" ExcludeProjConfig="Debug"/>
<File Name="src/TopFrame.cpp" ExcludeProjConfig="Debug"/>

And put whatever error-triggering garbage in those excluded files.

if you select "Build Workspace", CL will build the project and correctly ignore those files, but if you edit a file then just press F5 for Start/Continue Debugger, CL will try to compile and link the excluded files as well just before running.

thx & cheers,

-- p

[petah]

a simpler test case from scratch:

- new project -> simple executable g++
- add new file "dummy.cpp"
- type random garbage text in dummy.cpp (make sure it's not compilable)
- exclude file "dummy.cpp" from build
- menu -> build workspace
= ok
- add more garbage to dummy.cpp
- menu -> GDB -> start/continue debugger
= fails

thx & cheers,

-- p

[petah]

It looks like this bug is back, i.e. F5 runs without detecting/recompiling any changed source files so that a user has to manually Build the project first.

It only occurs when LLDB is selected though; it works fine when project settings use GDB, i.e. any changes are correctly detected and rebuilt on F5 before launching the project binary.

Not sure if it's related but LLDB/localhost doesn't set up the WorkingDirectory specified in the project prefs. I tried tracing it through LLDB's startup code but there are too many CWD changes: in the current ENV, inside ToJSON(), and one place where it's deduced from the binary full path.

To test the above I created a basic wx GUI project from CL's wizard and just added

Code: Select all

wxGetCwd()

to the "Click Me" string. To reproduce the bug switch from GDB to LLDB, edit & save some source file and press F5 without manually rebuilding first.

Both CL and wxWidgets were built from trunk on Debian Wheezy x64 with gcc 4.7, so was the test project. Neither clang nor libc++ were involved. Let me know if you need more details

thx & cheers,

-- p

ps: a side-effect of this bug will show mismatched lines when stepping through code with LLDB

[eranif]

Should be fixed in git head now

Eran

[petah]

great, build before debug detection is fixed but it seems the project's working directory still isn't being set. Just an initial observation, I'll run some tests to confirm it, will report back asap.

thx & cheers,

-- p

[petah]

running the wx wizard project mentioned earlier I confirm the CWD isn't being set (or rather, gets reset). In its debug config the wx UI wizard project sets the WD to $(IntermediateDirectory), which is "./Debug", but on execution, wxGetCwd() will return the base project folder under LLDB.

A possible clue may be in CodeLiteLLDBApp.cpp inside InitializeLLDB(), where

Code: Select all

if (!command.GetWorkingDirectory().IsEmpty())

is false, i.e. the command's m_WorkingDirectory field is empty, which I found odd.

I also wondered if rewriting the env var hashmap might reset the CWD but again they're just hunches. Let me know if I should upload the test wx project I used.

thx & cheers,

-- p