Author Topic: Bug Report: [#18755] C::B hangs for 20 seconds while opening large project...  (Read 62965 times)

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
What also doesn't work:

Have this layout:
[Root][src] - file.cpp
[Root]proj.cbp
- Open project
- Save project under:
[Root][prj] - proj.cpp

-> All files are broken, project file is broken.

Did this work previously?

To clarify, try the following:

1. open project
2. save project as -> move one directory up and click save
3. close project
4. reopen project -> all broken links

I tried applying Jens' latest patch, but that didn't appear to help with this issue.

EDIT: I'm guessing we need to do something more like ProjectFile::Rename for each file in the project if the project file is saved to a different place. i.e. we need to update relativeFilename and not just relativeToCommonTopLevelPath of each ProjectFile and any relative target/project paths.
« Last Edit: October 24, 2012, 11:14:48 pm by dmoore »

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
EDIT: I'm guessing we need to do something more like ProjectFile::Rename for each file in the project if the project file is saved to a different place. i.e. we need to update relativeFilename and not just relativeToCommonTopLevelPath of each ProjectFile and any relative target/project paths.

Please test this patch, it calculates the relativeFilename also.
It uses the relative expensive MakeRelativeTo-function again, but only in case the project and the file are on the same volume or below the same UNC path, so it might avoid the slowdown.

UNC-handling is not (yet) tested.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
what about if everything is on the same UNC path (project and project files). Are you suggesting that the files in this project should always be treated as absolute? (I hope not.)
Nope. In that case using relative path might be OK again. What I meant is if just the project file itself (and maybe 1..n , while n<max. project files) are on an UNC path. Whereas in that case all files that are relative to the project file on the same drive or same UNC base path can be relative as usual.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Please test this patch, it calculates the relativeFilename also.
Which one? Did you forget to attach a new, or do you mean the latter?
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Please test this patch, it calculates the relativeFilename also.
Which one? Did you forget to attach a new, or do you mean the latter?
Forgotten, sorry.
It was a little late last night, I think.
Here it is .

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Here it is .

Ok, that resolves the broken links after saving a project to a new folder. Projects with relative build paths get built in different locations now, of course... Guessing this will also break builds  when there a link libs specified on relative paths. (e.g. the ..\..\devel linker path that we use in CB), but it might be enough to warn the user if they change the project path that they will need to manually update these things?

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Here it is .

Ok, that resolves the broken links after saving a project to a new folder. Projects with relative build paths get built in different locations now, of course... Guessing this will also break builds  when there a link libs specified on relative paths. (e.g. the ..\..\devel linker path that we use in CB), but it might be enough to warn the user if they change the project path that they will need to manually update these things?
This surely breaks it, but trying to update each and any possible path will surely lead to other errors.

EDIT:
And as posted before, it is not related to the patch.
« Last Edit: October 25, 2012, 09:03:57 pm by jens »

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Projects with relative build paths get built in different locations now, of course...
BTW: It was always like that. In the past you were able to save the project file to different locations and the project file was updated accordingly. So yes, this breaks such things, but that would be the same for every IDE out there. And I think it should be pretty cleasr.

However, as also many Newbies use C::B - an AnnoyingDiaolg maybe worth a try...
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
What probably could be done in the Project SaveAs routine, is updating relative paths like workdir etc, but this would be ahidden magic, which can lead to broken projects as well as not doing this.
So an annoying dialog, before the project's new base-path is changed is the best thing.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
But what if the projectfile (*.cbp) has an UNC path ?
You mean if its on an UNC path? In that case, all files need to have absolute information and there is no common top-level path. But that doesn't matter, if all files have absolute path's... isn't it?

BTW: Testing the patch:
Unfortunately already the first trial fails miserably:
- create a project
- add a path on an UNC path
- file is immediately broken in project tree (although the "tree path" would be OK)
-> you cannot open/edit that file from the project tree.
(This I had just tried to fix in trunk recently...:-()
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
- file is immediately broken in project tree (although the "tree path" would be OK)
BTW: It seems there are two errors in that case:
- assume project on C:\Folder\project.cbp
- assume a file on \\server\folder\file.cpp
--> the file's absolute path is constructed from the common top level path plus the file's ("single slashed") UNC path like that:
C:\Folder\server\folder\file.cpp

--> the relative path is correct though:
\\server\folder\file.cpp

I'll commit a patch that will help to inspect what's going on in a minute...
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Unfortunately already the first trial fails miserably:
3rd post on that topic:

The rest seems to work well:
- saving project above/below source tree
- saving project on different drive
- having project files scattered across several drives

What does not work (and has very strange side-effects) is the following layout:

- project on/in C:\folder\project
- source files in C:\folder, C:\folder\src
- source files in D:\other_folder

--> now try to save the project under D:\other_folder\prj

--> weird project tree layout. including files with one letter, not existing.
--> seems the file name get truncated according the length of the folder

--> maybe its related to that check:
if ( tmpbaseF.GetDirCount() < base.GetDirCount() && ???
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
--> maybe its related to that check:
if ( tmpbaseF.GetDirCount() < base.GetDirCount() && ???
This should only be reached if the projects base-path is on the same volume as the file being processed.
If this worls correctly, this can not be the cause.
Maybe the base-path is not correctly set after saving the project on different drive ?

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Suddenly I'm starting to feel guilty for opening this can of worms  :-[

I'm so sorry!!! (But still, I don't want to go back to that 20-second delay on project opening)


Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Suddenly I'm starting to feel guilty for opening this can of worms  :-[
Its easy to re-recover: Come up with a patch that works! :-)
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ