Eugene,
I just tried the following (from a Mac admittedly, so it may be a Windows path issue):
1. Downloaded PTP Neon.2
2. Created a synchronized C++ project using the Hello World C++ Makefile Project type.
3. Called my remote host RHEL65.
4. After synchronizing, I get markers against stdio.h and stdlib.h and bug symbols on a couple of lines.
5. Go into the project properties > C/C++ General > Preprocessor Include Paths
6. Click on GNU C++ in the Languages box
7. Click on CDT User Setting Entries then Add
8. Change Project Path to File System Path
9. Enter "//RHEL65/usr/include" in the Path box
10. Select both Treat as built-in AND Contains system headers
11. Click OK
12. Repeat steps 7-11 for GNU C in the Languages box
13. Clicked OK
At this point the indexer ran and the markers were removed. I right clicked on the project and selected Index > Rebuild for luck.
I found any other combination (e.g. only configuring GNU C or GNU C++, only selecting Treat as built-in, etc. caused it not to work).
HTH, Greg
Things just aren't working out and I'm ready to abandon ship. I was able to add a samba share to map my library include files and those are indexed just fine (since it's just a file system path), but the remote system includes (I don't have a samba share for these) that are discovered by the Sync GCC Builtin Compiler Settings provider just aren't being indexed. It's a shame because it doesn't seem like my setup is particularly exotic. I appreciate the help you've tried to provide. I see. Connections and projects are independent, so RHEL65 should work. I just mean that the "RHEL65" connection exists with the context of the synchronized project. I don't know if it's visible outside of that project in a regular CDT project. Great - not sure what you mean by a "Generic Connection" though. Any connection should do, such I can give it a shot. Do I first need to add a "Generic Connection" in order to be able to reference it in the UNC path? I see. So this still seems to be a CDT problem. I wanted to rule out the possibility that the sync providers were somehow blocking the other includes.
If you get a chance, it would be helpful to know if these includes work with a plain, non-sync CDT project. Thanks
John I tried disabling the sync providers, leaving just the CDT User Setting Entries and rebuilding the index. It doesn't appear to have made a difference in that there are still a lot of unresolved includes/symbols. I see this near the top of indexer log file for specific file I tried to re-index: Local Include Search Path (option -iquote): Those are the 2 remote directories I added, however I can't tell if the indexer is actually attempting to reach to those remote locations. Thanks, Eugene Do the UNC entries in "CDT User Setting Entries" work if you disable the Sync providers? Thanks John. I'm trying to work around this by adding 2 remote directories under the "CDT User Setting Entries" using the UNC notation: <image001.png> However, it doesn't seem to wok. I've set both as "File System Path" and "Treat as built-in." <image002.png> A snippet from the indexer log for a specific file (for diagnostic purposes) is below. Note that the first set of system includes were discovered by the "Sync GCC Builtin Compiler Settings" provider. I don't know why the second set of directories is not being scanned/parsed. Include Search Path (option -I): Local Include Search Path (option -iquote): Thanks again, Eugene I think your analysis is correct. Java's "replaceFirst" method interprets its first argument as a regex, but our intent is for it to be a string. I'll file a bug report. The parser may work incorrectly only with certain directory names, so using a different directory might work, but I'm not sure... It depends on the details of how Java interprets regexes. Thank you for reporting this problem Hi, The Sync GCC Command Parser is not working on my Neon.1 (4.6.1) PTP (9.1.1.201612062209) installation. I believe the source is here: Is there something abnormal about my setup? It seems that in the code the remote path separator (Linux) is being changed to the local one (Windows), and then treats the backslash as an escape sequence (\F is not a valid one). java.util.regex.PatternSyntaxException: Illegal/unsupported escape sequence near index 30 \data\eugene.smolenskiy\depot\FMW\FH\MDP3FH\main ^ at java.util.regex.Pattern.error(Unknown Source) at java.util.regex.Pattern.escape(Unknown Source) at java.util.regex.Pattern.atom(Unknown Source) at java.util.regex.Pattern.sequence(Unknown Source) at java.util.regex.Pattern.expr(Unknown Source) at java.util.regex.Pattern.compile(Unknown Source) at java.util.regex.Pattern.<init>(Unknown Source) at java.util.regex.Pattern.compile(Unknown Source) at java.lang.String.replaceFirst(Unknown Source) at org.eclipse.ptp.internal.rdt.sync.cdt.core.SyncGCCBuildCommandParser.getWorkspacePath(SyncGCCBuildCommandParser.java:121) at org.eclipse.ptp.internal.rdt.sync.cdt.core.SyncGCCBuildCommandParser.setSettingEntries(SyncGCCBuildCommandParser.java:71) at org.eclipse.cdt.managedbuilder.language.settings.providers.AbstractLanguageSettingsOutputScanner.processLine(AbstractLanguageSettingsOutputScanner.java:492) at org.eclipse.cdt.managedbuilder.language.settings.providers.AbstractBuildCommandParser.processLine(AbstractBuildCommandParser.java:274) at org.eclipse.cdt.internal.core.ConsoleOutputSniffer.processLine(ConsoleOutputSniffer.java:178) at org.eclipse.cdt.internal.core.ConsoleOutputSniffer.access$0(ConsoleOutputSniffer.java:174) at org.eclipse.cdt.internal.core.ConsoleOutputSniffer$ConsoleOutputStream.checkLine(ConsoleOutputSniffer.java:99) at org.eclipse.cdt.internal.core.ConsoleOutputSniffer$ConsoleOutputStream.write(ConsoleOutputSniffer.java:58) at java.io.OutputStream.write(Unknown Source) at org.eclipse.ptp.internal.rdt.sync.cdt.core.remotemake.RemoteProcessClosure$ReaderThread.run(RemoteProcessClosure.java:95) Thank you, Eugene This message is intended only for the stated addressee(s) and may be confidential. Access to this email by anyone else is unauthorized. Any opinions expressed in this email do not necessarily reflect the opinions of Fidessa. Any unauthorized disclosure, use or dissemination, either whole or in part is prohibited. If you are not the intended recipient of this message, please notify the sender immediately. This email does not form a contract and we do not represent that it is complete, accurate, uncorrupted or free of viruses and it should not be relied upon as such. _______________________________________________ptp-user mailing listptp-user@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://dev.eclipse.org/mailman/listinfo/ptp-user
|