Re: [ptp-user] Remote Indexing Issue with PTP 6.0.3 and Remote Indexing

[Beth Tibbitts <tibbitts@xxxxxxxxxx>]

Corey:
Next time I want someone to run experiments and document all the things they tried, I'm hiring you!

I'm not sure how you're setting the include paths, but do what we say in the SC12 tutorial
(slides at http://wiki.eclipse.org/PTP/tutorials/SC12) but note the wiki will be down tomorrow/Saturday while they move the servers!)
page Editor-5 and Editor-6  which is PDF pages 98-99
.. which says to use Project Properties, C/C++ General, Preprocessor Include paths, CDT User Setting Entries, Add, and select 'Filesystem' in the pulldown in the dialog where
you put the UNC path.

Does that help?


...Beth

Beth Tibbitts
Eclipse Parallel Tools Platform  http://eclipse.org/ptp
IBM STG - High Performance Computing Tools
Mailing Address:  IBM Corp., 745 West New Circle Road, Lexington, KY 40511

Corey Ashford ---02/08/2013 03:24:07 PM---On 02/08/2013 05:42 AM, Beth Tibbitts wrote: > CDT patch for UNC names in include paths is on the SC

From:	Corey Ashford <cjashfor@xxxxxxxxxxxxxxxxxx>
To:	PTP User list <ptp-user@xxxxxxxxxxx>,
Date:	02/08/2013 03:24 PM
Subject:	Re: [ptp-user] Remote Indexing Issue with PTP 6.0.3 and Remote Indexing Patch
Sent by:	ptp-user-bounces@xxxxxxxxxxx

---

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

_______________________________________________
ptp-user mailing list
ptp-user@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-user