[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Toolchains in CDT
|
In our product you can set multiple toolchains even for a single
project. For example, a single project can be compiled for two
different architectures. This is how we deal with different versions of
gcc, etc. Usually that would appear as a two separate toolchains.
Overriding a single tool on a per-project (or probably per-configuration
for managed make) could be useful, I'd have to think about an interface
for making that generic.
Yes, this is a reasonable level of granularity. We also support that, so
user can specify different toolchain for different target platforms. By
default all platforms this project support use one and the same
toolchain. However fot some of them it could be redefined.
2. A toolchain should have the capability to export a list of include
paths and library paths. Managed make should at least be able to use
this to automatically supply them to the parser for content assist, etc.
Probably we could make use of this in standard make as well, but maybe
not right away.
I think this is what we expect from implementation of
IScannerInfoProvider and IScannerInfo interface (defines and includes).
Did you mean that?
Jeremiah Lott
TimeSys Corporation
-----Original Message-----
From: Alex Chapiro [mailto:achapiro@xxxxxxx]
Sent: Monday, February 16, 2004 8:09 PM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] Toolchains in CDT
I am not sure could it be interesting for this discussion. Just FYI .
In Momentics we are using two-tiers toolchain specification. First level
let us to select a particular toolchain (in our terms SDK because
toolchain is not only a set of tools but also libraries and include
headers) per workspace (we are going to change it to select toolchain
per project). Toolchain being selected, specify default for this
toolchain set of tools . On the second level (per project/per build
step, now for compilation step only) we provide an ability to redefine
particular tool , i.e. to use a tool other than default one. This can be
useful if in SDK there are different versions of one and the same tool,
for example different versions of gnu compiler.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev
