Works for me for ".C", but not for ".S".
Apparently duplicates are eliminated from the list for a content type using the
case-insensitive matching, although I didn't trace through the code to figure
out where or why. So you can map ".c" and ".C" to different content types,
but not ".s" and ".S" to the same content type. It only preserves the
first one so if I change it to "S,s,asm" then only capital works. If I
change it to "s,asm,S", then only lowercase
works.
Jeremiah
-----Original Message----- From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of
Lott, Jeremiah Sent: Friday, July 22, 2005 3:41 PM To:
CDT General developers list. Subject: RE: [cdt-dev] Loose end # 2 -
content typeextensionsandcasesensitivity
Sorry, I guess my investigation was
incomplete. If this works I would much prefer this too. Thanks
Leo,
Jeremiah
I just tried a test
on Windows:
1. Created an
MBS C++ project and added a .C file.
2. The MBS
build does not include the .C file.
3. Changed
org.eclipse.cdt.core\plugin.xml, to add uppercase C to the list in
org.eclipse.cdt.core.cxxSource.
4. The MBS
build includes the .C file because the MBS call to
IContentType.getFileSpecs(IContentType.FILE_EXTENSION_SPEC); returns the
file extensions with case preserved.
I suggest that I
don’t change the MBS, and that we DO add .C and .S to the appropriate
content types in cdt.core.
Leo
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Lott, Jeremiah Sent: Friday, July 22, 2005 2:55
PM To: CDT General
developers list. Subject:
RE: [cdt-dev] Loose end # 2 - content
typeextensionsandcasesensitivity
It's not JDT
behavior, it is core platform behavior. I agree 100%, but you can't
even specify .c and .C as separate extensions. The content type system
automatically converts any extension to lowercase before doing a
compare. All extension methods return lowercase, regardless of what
you specify in plugin.xml or in the UI. I actually modified CDT to
include a content type mapping for ".S", but it made no difference as the
platform converted it to lowercase after reading it.
-----Original
Message----- From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Recoskie,
Chris Sent: Friday, July
22, 2005 2:55 PM To: CDT
General developers list. Subject: RE: [cdt-dev] Loose end # 2
- content type extensionsandcasesensitivity
I don’t think we
can follow that per se though as we have to build .c files as C and .C
files as C++
Do we really know
if this is defined Eclipse behaviour or is it just the way that JDT has
implemented it?
If the API spec
doesn’t specify one way or the other then I’d say we’re free to handle it
whichever way we wish, i.e. in a case sensitive manner.
___________________________________________
Chris
Recoskie
Texas Instruments,
Toronto
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Lott,
Jeremiah Sent: Friday,
July 22, 2005 2:32 PM To:
CDT General developers list. Subject: RE: [cdt-dev] Loose end # 2
- content type extensions andcasesensitivity
My investigation
lead me to believe that Eclipse treats all file extensions in content
types as case insensitive on all platforms (I tried windows and
linux). This was independent of CDT. I tried JDT, adding
extensions like ".JAVA", and also by inspecting the Eclipse content
type code. I would actually prefer they be case-sensitive, but given
this Eclipse behavior, I don't see any choice but to follow the
requirements set by the Eclipse platform and treat them
as case-insensitive.
-----Original
Message----- From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Treggiari,
Leo Sent: Friday, July
22, 2005 2:35 PM To:
CDT General developers list. Subject: [cdt-dev] Loose end # 2 -
content type extensions and casesensitivity
In bug 103530, there is a
discussion of whether the file extensions specified for an Eclipse
content-type should be treated as case sensitive or case insensitive.
Currently, the MBS treats these as case sensitive on all
platforms. In there is a consensus on what is correct, and it is
different from the current MBS behavior, we could try to change this for
3.0. What do others think?
Thanks,
Leo
|