Closed GoogleCodeExporter closed 8 years ago
I think it has to do with the org.eclipse.core.contenttype.contentTypes
extensions,
I'll investigate how it gets c++ headers to parse correctly, I imagine we'll
have to
do the same.
Original comment by rrusaw@gmail.com
on 8 Jul 2009 at 1:40
The weird thing is I'm sure it used to a few weeks back - I'm going to have to
step back and see what
changed. It is to do with the content type though - there's an objcsource and
objcheader defined.
Original comment by alex.ble...@gmail.com
on 8 Jul 2009 at 8:15
I've not been able to find an older version where this was working. There is an
objcHeader variant, but it
doesn't appear to be picked up - I'm going to see if i can find the history
where it used to work before.
Original comment by alex.ble...@gmail.com
on 8 Jul 2009 at 11:18
There must be something we are missing...
Even if I manually associate *.h as "Objective C Source File" via the project
Properties->C/C++ General/File Types interface the GNUObjCSourceParser is never
run
by the reconciliation thread. In fact, none of the AbstractCSourceParser
subclasses
are run at all for it, its as if it is a regular text file. However,
associating *.h
with the C or C++ source files causes the appropriate source parser to be used.
Is it perhaps related to the ParserLanguage enum? Which only contains values C
and CPP.
Original comment by rrusaw@gmail.com
on 9 Jul 2009 at 5:00
This may be useful to know:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/xlc/org.eclipse.cdt.man
agedbuilder.xlupc.ui/src/org/e
clipse/cdt/managedbuilder/xlupc/ui/wizards/XLUpcSettingsWizardRunnable.java?
root=Tools_Project&view=markup
Original comment by alex.ble...@gmail.com
on 9 Jul 2009 at 2:55
Fixed (for newly created projects) in r87
Original comment by alex.ble...@gmail.com
on 9 Jul 2009 at 9:35
Original comment by alex.ble...@gmail.com
on 9 Jul 2009 at 9:50
Original issue reported on code.google.com by
alex.ble...@gmail.com
on 8 Jul 2009 at 12:27