Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Fix for Bug #18744?

(1/3) > >>

MortenMacFly:
Windows users/devs: Attached is a patch to probably fix bug #18744:
http://developer.berlios.de/bugs/?func=detailbug&bug_id=18744&group_id=5358

...please give it a try and report back. Within the bug description there is also a way how to reproduce this.

oBFusCATed:

--- Quote ---This bug was introduced between nightly 7966 and 8024.
--- End quote ---
Which is the exact revision, where the bug have been introduced?

MortenMacFly:

--- Quote from: oBFusCATed on October 11, 2012, 09:10:24 pm ---
--- Quote ---This bug was introduced between nightly 7966 and 8024.
--- End quote ---
Which is the exact revision, where the bug have been introduced?

--- End quote ---
I would guess this:
* r7986: jenslody: fix calculation of relativeToCommonTopLevelPath in cbproject.cpp; fixes issue described here: http://forums.codeblocks.org/index.php/topic,16322.msg110516.html#msg110516

Jenna:
As far as I know we never really handled files on different volumes, even if it (accidently ?) might have worked before.

If I see it correctly, th erelevant part of the patch is this one (just cosmetical changes on the other places) :

--- Code: ---@@ -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
 {

--- End code ---

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.
If the files are on different volumes m_CommonTopLevelPath is just empty and all files have to use absolut paths as relativeToCommonTopLevelPath.


By the way, I explicitely wrote, that I did not test it with files on different volumes:


--- Quote from: jens on May 15, 2012, 02:50:11 pm ---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.

--- End quote ---

MortenMacFly:

--- Quote from: jens on October 12, 2012, 06:49:26 am ---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.
If the files are on different volumes m_CommonTopLevelPath is just empty and all files have to use absolut paths as relativeToCommonTopLevelPath.

--- End quote ---
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.

Furthermore, if you look at the sources, in the above loop we have no wxFileName objects, but the path's are stings. I didn't want to implement a hacky volume extraction method and also taken into account that such calls are really costly I wanted to minimise the attempts for these very rare use-cases. Already now it slows down the calculation a lot and we all know what that means... count how often and when and where this method is called and you know what I mean. ::)


--- Quote from: jens on May 15, 2012, 02:50:11 pm ---I did not test what happens, if files in a project are on different drives in windows.

--- End quote ---
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.

Navigation

[0] Message Index

[#] Next page