Hi Greg,
Unfortunately this didn't work.
I see the following in an index log file for a particular file.
Include Search Path (option -I):
\\RHEL65\usr\include ß
Configured this as build-in and system headers for C++ and C
Z:\fh_release\v5.2.0a\release64\include
ß samba share, works fine
I:\infrastructure_release\v9.1.4\core\release64\include
ß samba share, works fine
.
.
.
Unresolved includes (from headers in index):
ssh://RHEL65/usr/include/Db.h is not indexed
ssh://RHEL65/usr/include/inttypes.h is not indexed
Unresolved inclusion: inttypes.h in file file:/I:/infrastructure_release/v9.1.4/core/release64/include/UtlArrys.h
Unresolved inclusion: string.h in file file:/I:/infrastructure_release/v9.1.4/core/release64/include/UtlArrys.h
.
.
.
From: ptp-user-bounces@xxxxxxxxxxx [mailto:ptp-user-bounces@xxxxxxxxxxx]
On Behalf Of Greg Watson
Sent: Tuesday, February 14, 2017 1:02 PM
To: PTP User list
Subject: Re: [ptp-user] PatternSyntaxException in Sync GCC Build Command Parser
Eugene,
I just tried the following (from a Mac admittedly, so it may be a Windows path issue):
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
12. Repeat steps 7-11 for GNU C in the Languages box
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).
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.
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.
Do the UNC entries in "CDT User Setting Entries" work if you disable the Sync providers?
I'm trying to work around this by adding 2 remote directories under the "CDT User Setting Entries" using the UNC notation:
However, it doesn't seem to wok. I've set both as "File System Path" and "Treat as built-in."
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):
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
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)
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 list
ptp-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ptp-user
|
