Patch to make cmakeManager return clean path
Andreas Pakulat
apaku at gmx.de
Sun Nov 15 18:41:32 UTC 2009
On 15.11.09 17:21:11, Benjamin Schindler wrote:
>
>
> Andreas Pakulat wrote:
> >On 15.11.09 15:33:17, Benjamin Schindler wrote:
> >>Hi
> >>
> >>Quite often one gets include path from cmake such as:
> >>/some/build/dir//someincludeDir
> >>
> >>Even though such a path is valid, some comparisons fails (such as the
> >>one in includepathcomputer.cpp:208:
> >>
> >> m_hasPath.contains(r)
> >>
> >>The attached patch fixes this problem. However, I'm not sure whether
> >>this is the correct solution. The m_hasPath.contains(r) should succeed imho
> >
> >Exactly, a plain-string check most certainly is the worst way of
> >testing. I can also think about symlinks and the like easily breaking
> >this.
> How should links break this? Could you post me a scenario? If a file
> is accessible by two directory path through simlinks, at least one
> working one has to be in the include path list. May be I
> misunderstand how you retrieve the path r?
I guess I'm missing out the context of the above, can't come up with an
example, so just ignore that :)
> But then again, m_hasPath.contains probably does equality checks
> through the == operator, so this comparison should not fail imho as
> is.
I guess its a list of strings or something, which will of course fail if
the strings are different. However instead of strings it should have an
object of type Path or something which has proper ==-semantic built in.
Andreas, waiting for David to scream about memory consumption and
speed issues :)
--
You had some happiness once, but your parents moved away, and you had to
leave it behind.
More information about the KDevelop-devel
mailing list