Re: [cdt-dev] Shared tool settings between tools?

[Mike Wrighton <mike.wrighton@xxxxxxxxxxxxxx>]

2009/4/3 Alex Blewitt <alex.blewitt@xxxxxxxxx>:
> I've had some success in getting the Objective C support going - I've
> defined an ObjC Compiler tool (which adds the mapping between m->o files)
> and ObjC Linker tool (to add the -framework line). In the end, it was
> largely changes in the plugin.xml
> (http://code.google.com/p/objectiveclipse/source/browse/trunk/org.eclipse.cdt.objc.core/plugin.xml).
> One question I have is how to defined shared settings between the linker and
> the compiler. It's not really a major issue, but since I was in the code
> anyway, I wanted to add -arch to the flags as well. I think this is needed
> for both the linker and compiler, but when I defined the optionCategory and
> option in both places, it seemed that the values for the -arch in the
> compiler weren't replicated in the changes for -arch for the linker (which
> would be a bit annoying). I thought it might be possible to share the
> settings somehow between the two? I've got the <tool> definitions in the
> above google code link if anyone can shed obvious light (though I've
> commented the -arch out right now).

I had a similar requirement and soved it by providing a
commandLineGenerator for each tool that needed to replicate a setting
in
another tool, and inserted it into the command line. e.g. the linker
has a target option, and when you set it, the compilers and any other
tools in the chain include --arch=... in their output. You need to
implement generateCommandLineInfo() and search for the original
tool/setting. A bit hacky but it does the trick.



> The second question I have is how to enable the ObjC compiler/linker by
> default for the objc projects. I've defined the tools with a nature filter
> (relies on CDT Bug 270879 but I don't think it's a show-stopper if it shows
> up accidentally anyway). Oddly, when you select ObjC Compiler, it wants to
> replace the existing GCC compiler (tool definition below), but when I select
> the ObjC linker, it wants to add it to the list.
> natureFilter="objcnature"
> id="cdt.managedbuild.tool.gnu.objc.compiler"
> name="%objc.compiler.name"
> superClass="cdt.managedbuild.tool.gnu.c.compiler">
>
> natureFilter="objcnature"
> id="cdt.managedbuild.tool.gnu.objc.linker"
> name="%objc.linker.name"
> superClass="cdt.managedbuild.tool.macosx.c.linker">
>
> The change to the compiler, to add the 'objcSource' type and definition
> should be applicable to any gcc-based tool, so I'm not even sure if it makes
> sense to have a separate ObjC compiler - or whether this is just a
> convenient stepping-stone. The change to the linker (adding -framework) is
> only specific to the Mac OS X linker though (but could easily replace the
> existing linker).
> I'd like to know if I'm on the right track here, and whether I should try
> and create a replacement toolset which would include the ObjC
> compiler/linker by default in place of the existing ones.
> Alex
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>