[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ptp-user] Remote Indexing Issue with PTP 6.0.3 and Remote Indexing Patch
|
On 02/08/2013 05:42 AM, Beth Tibbitts wrote:
CDT patch for UNC names in include paths is on the SC12 tutorials page
http://wiki.eclipse.org/PTP/tutorials/SC12
and should be in the Juno SR2 release of Eclipse/CDT shortly. (That's
one of the things I want to test today.)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=396651 - I've been told
it's been fixed in CDT now.
This is *not* a "remote indexing" patch. This is a patch to CDT to
correctly use the UNC syntax of //connection/path/to/remote/file for
local indexing.
Remote Indexing is used by remote projects - it happens on the remote
system and the results are brought to the workstation over the connection.
I assume you're using a synchronized project, where the files are
mirrored on both local and remote, indexing works locally
(utilizing UNC path to find remote files) and build is usually done on
the remote target.
Thanks for the replies, Greg and Beth!
I now have the CDT patch installed, and PTP 6.0.3 installed.
I am using a synchronized project, and RemoteTools for the connections.
I have some code located on a remote machine, and its "normal" header
files (e.g. /usr/include/string.h) are located in an unusual location.
I have added that remote path, but the indexer still seems to be looking
in the local include directories first.
Here are some experiments I tried, with some very odd results:
Experiment 1: Since the real /usr/include/string.h that I want was in a
long, complex pathname with odd characters in it, I decided to add
another path to the remote machine's standard /usr/include to see if the
indexer would find it (//<connection>/usr/include). I inserted this
new path ahead of the longer one, and rebuilt the index.
Result 1: Indexer still found the local /usr/include
Experiment 2: Try to force the indexer to find the remote string.h by
renaming my local /usr/include/string.h, to /usr/include/string.h.save
(I know, dangerous!), then rebuild the index.
Result 2: Indexer now finds string.h at on the remote connection, but
strangely doesn't find the one in /usr/include, but instead finds the
one on the longer path, that's behind /usr/include in the search order.
Experiment 3: Switch the order of the include directories and rebuild
the index.
Result 3: No difference. Indexer still finds string.h in the longer
include path.
Experiment 4: Try to force the indexer to find the string.h in
//<connection>/usr/include by *removing* the longer remote include path.
I removed it for all languages, then rebuilt the index. There is no
longer a visible remnant of the longer path.
Result 4: Indexer is still finding the string.h at the longer path,
which no longer exists in the configuration!!
Experiment 5: Restart eclipse, examine that project settings to verify
that the longer path doesn't exist, then rebuild the index.
Result 5: Same result. Indexer is still finding string.h at the longer
patch which is no longer in the project config.
Experiment 6: Run "Sync All Now" on the project, and rebuild the index.
Result 6: No difference.
Experiment 7: Try "Indexer->Re-resolve unresolved includes" just as a guess.
Result 7: No difference.
So I couldn't understand where the longer path was coming from still.
On a hunch, I looked in the "Default_with_Linux GCC_local" build
configuration, and there was the path. It must have got there because I
specified "Add to all configurations" at one point. Once I deleted the
longer path there (leaving no extra include paths), the indexer could
not find string.h at all, even though my project has selected the
"Default_with_Remote Linux GCC Tool Chain_remote" configuration, and the
path to string.h exists in that build config.
Experiment 8: delete all extra paths in both build configurations, then
add only the long path to the "Default_with_Linux GCC_local" build
configuration, only under GCC C, but double check that the build
configuration used by my project is "Default_with_Remote Linux GCC Tool
Chain_remote", and rebuild the index.
Result 8: The indexer was able to find my string.h in the remote location.
It seems to me that the CDT include path search mechanism is messed up:
1) The indexer always looks in local directories first, and doesn't
display what those directories are under the GNU C and GNU C++ Paths and
Symbols -> Includes tab, nor in Preprocessor Includes -> Entries tab.
2) It doesn't pay any attention to the build configuration used by the
project, and seems to always default to the settings provided in the
"Default_with_Linux GCC_local" build config.
In conclusion:
For me, the state that it's in today is unusable, because of the
searching of local paths overriding remote paths.
I could put up with the index using the wrong build config, but that's
quite annoying and confusing.
- Corey
