Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Rebuilding managed build project on properties change

> You are right, the tool-chain options changes themselves do not result
> in a full rebuild. This was done intentionally. My assumption was that
> the tool-chain options are not the build options themselves, i.e. not
> used by makefile generation, etc. Instead they are used to
> initiate/perform a [simultaneous] change of some build options (e.g.
> tool option values, build environment, build macros, etc.).
> That is why no full rebuild is initiated by the tool-chain option
> change. Instead it is expected that the proper rebuild state will be set
> by the build settings change initiated by the tool-chain option
> modification (e.g. via a tool-chain option value handler).
> I might be wrong with my assumption. In this case we may consider
> changing the build logic to always perform a full rebuild after the
> tool-chain option is modified.

I moreless figured this was the case. Currently we use one of the methods
Volodya mentioned, which is to have our own commandline generator that cats
the global options to the tool specific options. E.g. the toolchain-level
CPU option just results in a -C<cpu> option being added to all separate
tool command lines, apart from that the state of these tools is not

I guess 'ideally' the build manager should check the resulting command line
to see if any options changed with respect to the previous build. In that
case a global toolchain-level option change that for instance does not
affect the compiler options does not result in compiler tool invocation. So
the disadvantage of doing a full rebuild after any toolchain-level option
changes is that this might cause some redundant tool invocations. Volodyas
proposal to set the rebuildState per tool by the valueHandler does not seem
to be a bad solution for that matter.


Back to the top