Community
Participate
Working Groups
This "S" extension is not recognized, even though it is declared in the plugin.xml for the assembler inputType in the managed build description. Apparently this is because it now uses the "content type" system, which overrides any file-extension declared in the input type. The assembler content type seems to be defined as ".s" and ".asm", but not ".S". This extension was recognized by the managed builder in CDT 2.0.
Upon further investigation, I should also add that I am unable to add ".S" for assembly on the content type preference page. It appears to be because the content type panel is treating the extensions as case-insensitive (I am on windows), and sees ".S" as a duplicate of ".s". The managed build systems seems to treat the extensions as case-sensitive, however.
That's probably the root of it and the mishandling of .C as well. I guess we need to add case sensitivity as a toolset option. Yuck...
The source content-types are defined in org.eclipse.cdt.core\plugin.xml. <extension point="org.eclipse.core.runtime.contentTypes"> <file-association content-type="org.eclipse.cdt.core.cSource" file-extensions="c"/> </extension> <extension point="org.eclipse.core.runtime.contentTypes"> <file-association content-type="org.eclipse.cdt.core.cxxSource" file-extensions="cpp,cxx,cc"/> </extension> <extension point="org.eclipse.core.runtime.contentTypes"> <file-association content-type="org.eclipse.cdt.core.asmSource" file-extensions="s,asm"/> </extension> <extension point="org.eclipse.core.runtime.contentTypes"> <file-association content-type="org.eclipse.cdt.core.cHeader" file-extensions="h"/> </extension> <extension point="org.eclipse.core.runtime.contentTypes"> <file-association content-type="org.eclipse.cdt.core.cxxHeader" file-extensions="hpp,hh,hxx"/> </extension> There are no uppercase extensions in these lists. Even if we were to do case insensitive compare on Windows, there would still be a problem on other platforms. Questions: 1. Should "S" and "C" be added? Note: I can't change cdt-core. 2. Should the MBS have a tool-chain attribute that states whether file extensions are case sensitive? Windows does give us file names and extensions in the case that they were created. That is, an MBS C project will not compile a file with a "C" extension by default.
After doing a little more research, it appears to me that Eclipse content types are case-insensitive on all platforms (including windows & linux). I guess the managed build system will have to take that into account somehow. I base this on looking at org.eclipse.core.internal.content.FileSpec, which is used for all the ContentType matches. It turns everything to lower case and/or does case- insensitive matching.
This problem is still present in CDT HEAD as of today. Adding both *.s and *.S in the "C/C++ General"->"File Types" tab of project properties results in an error.
Created attachment 76547 [details] A workaround I attach a patch that works around the problem -- the managed builder no longer users Eclipse core, but basically uses a hardcoded list of extensions (s + S). This is not ideal, because users can't add new extensions, but given that now S extension does not work at all, is probably an improvement over the current situation.
I noticed that the "S" extension is still not recognised by the build system and that it is still not declared as a content type. Adding "S" as a "org.eclipse.cdt.core.cSource" content type works nicely as GCC will figure out what to do. I added the following declaration to our code: <extension point="org.eclipse.core.runtime.contentTypes"> <file-association content-type="org.eclipse.cdt.core.cSource" file-extensions="S"/> </extension> And "S" files are correctly handled by GCC.
The content type support in the platform was extended at some point to handle case sensitivity. Should be easy to just add the uppercase version now.
I added .S and .ASM to the content type definition. Fixed on HEAD.
It looks like it is not fixed in CDT 6.0. See: https://bugs.eclipse.org/bugs/show_bug.cgi?id=278026
