[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] How the managed build system will deal with built-in in clude paths and symbols
|
The most important reason for using macro substitution for directory
specification is the need to share projects between users..
${workspace_root} and $(project_root) is not enough to make the project relocatable.
Actually to support projects that were created out of workspace, something like $([project_name]_root)
can work properly.
Sean Evoy wrote:
Hi All,
This is a message for people working on the managed build system. Rather
than duplicating this discussion in two places, I would like to invite
anyone who is interested in the managed build system and how it deals
with compiler built-in paths and symbols to make comments in Bugzilla
Bug 44279 "Include Paths & Toolchain Path Settings". It contains a
suggestion to use IVariables to encode the roots of paths in the
manifest, an alternative suggestion to extract these values by parsing
the output of a compilation, and a hybrid approach that involves both.
What I am looking for is feedback from people who have thought through
the challenge of implementing their own build tools in the managed build
system, and whether one approach would be easier for you to implement
for your tools. For example, any solution that relies on the output of a
build to resolve variable values requires that there be some way to
convince the compiler to tell you what those values are, either via the
command line or a settings file you can read in, etc.
Anyway, I don't want to influence the discussion before it starts.
Please give the proposals some thought and weigh-in with your own
opinions. Thanks,
Sean Evoy
Rational Software - IBM Software Group
Ottawa, Ontario, Canada
