Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Toolchain woes

Wieant Nielander wrote:
>> I tried to create a single tool for C and C++ compilations, since it is
>> the same physical binary responsible for both. Also, the compiler
>> options are identical, and I'd prefer not having to duplicate them in
>> two tools. When I tried adding two input types to the tool (one for c
>> and one for c++), CDT attempted to pass source code files multiple times
>> to the compiler (which casued a fatal compiler error). I tried to fiddle
>> around with the "primaryInput" attribute, but to no success. Is it
>> possible to have a single tool for C and C++, and if so, how?
> 
> Once again we use this same approach, and in our case using a single
> tool for C and C++ does seem to work fine, below an excerpt from one
> of our toolsets:
> 
>       <tool
>             command="cc166"
>             commandLineGenerator="com.tasking.managedbuilder.TskManagedCommandLineGenerator"
>             name="C/C++ Compiler"
>             outputFlag="-c -o"
>             id="com.tasking.c166.cc"
>             announcement="Compiling ${&lt;F}"
>             errorParsers="com.tasking.managedbuilder.TskErrorParser"
>             natureFilter="both">
>          <inputType
>                dependencyContentType="org.eclipse.cdt.core.cHeader"
>                dependencyExtensions="h,hpp"
>                id="com.tasking.c166.cppInputType"
>                multipleOfType="false"
>                name="C++"
>                primaryInput="true"
>                sourceContentType="org.eclipse.cdt.core.cxxSource"/>
>          <inputType
>                dependencyContentType="org.eclipse.cdt.core.cHeader"
>                dependencyExtensions="h"
>                id="com.tasking.c166.cpp.cInputType"
>                name="C"
>                primaryInput="true"
>                sourceContentType="org.eclipse.cdt.core.cSource"/>
> 
> 
> For a mixed C/C++ project this resulted in the following subdir.mk 
> makefile excerpt:
> 
> C_FILES += "../cstart.c"
> 
> "cstart.d" : "../cstart.c"
> "cstart.obj" : "../cstart.c"
> 	@echo Compiling ${<F}
> 	@"C:\tsk\c166-VX v2.1r3\bin\cc166" -c -o "$@" "$<" -Cc167 ...
> 
> C++_FILES += "../hello.cpp"
> 
> "hello.obj" : "../hello.cpp"
> 	@echo Compiling ${<F}
> 	@"C:\tsk\c166-VX v2.1r3\bin\cc166" -c -o "$@" "$<" -Cc167 ...
> 
> Note that we use our own makefile generator, but also the internal
> builder does not show any double calls. So it looks like it is possible
> to use a single C/C++ tool.
> 

I appears as the Tool class assumes that there can be only one primary
input type (see getPrimaryInputType() in the Tool class), and the Gnu
makefile generator returns an IPath object from
getAdditionalResourcesForSource (which are added to the command line)
for all resources which aren't of the primary input type, so I get:

iccarm [...] -o "$@" "$<" "../foo.cpp"

since foo.cpp is not a primary input type according to
getPrimaryInputType().

--
/Jesper





Back to the top