This bug was introduced between nightly 7966 and 8024.Which is the exact revision, where the bug have been introduced?
I would guess this:QuoteThis bug was introduced between nightly 7966 and 8024.Which is the exact revision, where the bug have been introduced?
@@ -360,13 +362,17 @@ void cbProject::CalculateCommonTopLevelPath()
ProjectFile* f = (*it);
if (!f)
continue;
wxString fileName = f->file.GetFullPath();
- f->relativeToCommonTopLevelPath = fileName.Right(fileName.Length() - m_CommonTopLevelPath.Length());
+ if ( f->file.GetVolume().IsSameAs(base.GetVolume()) )
+ f->relativeToCommonTopLevelPath = fileName.Right(fileName.Length() - m_CommonTopLevelPath.Length());
+ else
+ f->relativeToCommonTopLevelPath = fileName;
+
f->SetObjName(f->relativeToCommonTopLevelPath);
}
}
wxString cbProject::GetCommonTopLevelPath() const
{
Can you (and other devs) please test the attached patch ?
I did not test what happens, if files in a project are on different drives in windows.
Wouldn't it be better to handle the different volume issue when calculating m_CommonTopLevelPath and not (only) when setting the relativeToCommonTopLevelPath for the files belonging to the project.My thoughts were that if you really have source file on another drive that its most likely that these are 3rd party libs or alike (i.e. mounted on a network share), so you would also have at least some file on the drive where the project is, too. Really: Who on earth would have its sources completely on a different drive? ??? However - it would still work with my attempt.
If the files are on different volumes m_CommonTopLevelPath is just empty and all files have to use absolut paths as relativeToCommonTopLevelPath.
I did not test what happens, if files in a project are on different drives in windows.No worries - nobody is complaining. As I wrote in the bug report already: This is actually a bad project setup and if not special care is taken it will lead to further problems when it comes to debugging, for example.
Wouldn't it be the best to just skip files, that are on volumes, that differ from the volume the projectfile is on, when the common toplevel is calculated ?How?
How?Any ideas that came "over night"...?! ;-)
How?Any ideas that came "over night"...?! ;-)
I think we should do something about it - otherwise Workspaces are pretty much broken for this special cases.
I'm not at home at the moment (short brak at the northsea with my family until wednesday) so I have not really time to look into it, sorry.OK - no hurry then. BTW: It seems you are nearby to me atm... maybe we should held a dev-con at you way back... ;-) ;D
I'm not at home at the moment (short brak at the northsea with my family until wednesday) so I have not really time to look into it, sorry.OK - no hurry then. BTW: It seems you are nearby to me atm... maybe we should held a dev-con at you way back... ;-) ;D
Hey, Morten, thanks a lot! Your inspiration helped solve my 22-second project loading time! ;DWhat did I do to help?! ??? :o
I used your patch to handle files on different volumes and added aprt to skip files that are not on the same volume as the projects base-path when calculating the common toplevel path. But esecially this part needs more testing.Hey, Morten, thanks a lot! Your inspiration helped solve my 22-second project loading time! ;DWhat did I do to help?! ??? :o
Did you solve it? (Oh - maybe I should read the bug report fist...)