Re: [cdt-dev] PR 52864 : identification of translation units

["Alain Magloire" <alain@xxxxxxx>]

> 
> All,
> 
>   I've been talking with some folks about PR 52864,
> providing a way to customize how the core model
> identifies a translation unit.
> 
>   Attached is a proposed solution.  It presents a
> simple extension point and API for resolving file
> types.
> 
>   If this proposal seems reasonable, I'd start by
> implementing the API elements as part of the core
> (in org.eclipse.cdt.core), and adding declarations
> to the core plugin.xml for standard C/C++ file
> types.
> 
>   Once the core API is in place, I'd take a look at
> the next step - working on a preference page that
> would allow the user to create, replace, update, or
> delete file type resolution information.
> 
>   Comments?


Looking good.


*
Filenames especially for c++ can be a very long list.
for example "cstdio" etc .. to put all the names in the extension
can be cumbersome.
Would it be possible in the extension to have an extension attribute
to get the patterns from a list
<extesnion point= ...>
   filelist=template/cppfiles
...
</extension>

*
Noted that you have a ICFileType.isBinary().  We already have a scheme to discover
binary files.   Usually binary files can not be discover on filenames
alone, maybe it is true for Windows(I think, Cygwin has a scheme to deal with this).
And it can get heavier, if you have to deal with multiple format, XCoff/Elf/a.out/PE etc ..
I would say not to have this method here.

*
Some compilers make a difference between ".S" and ".s",  the ".S" is assembly
with processing symbols.  There is only
  ASM_SOURCE --> ".asm_source"

* 
I assume the ICFileTypeManager will be singleton on the CCorePlugin. 
I would advocate for a possibility to make/save on a per/project basis,
and it should be shared(whether by the the ICDescriptor mechanism or some other means).

So in your example, it should be
ICFileType type = CCorePlugin.getFileType(project, "foo.cpp");