[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Internal Builder
|
On 14 February 2011 22:32, Stan Mitchell <stanlmitchell@xxxxxxxxx> wrote:
> So if I wanted to support NMake, I would use GnuMakefileGenerator as a
> starting point, and modify it for NMake’s syntax.
That's probably the easiest thing to do.
> If I wanted to avoid that effort, would the internal builder be a good
> option?
I'm not sure who uses the internal builder. We use the makefile
builder exclusively here.
> Does CDT’s internal builder use .project and .cproject files to completely
> store its internal representation (or is more info needed)?
It uses those plus the toolchain definitions in the MBS extension point.
> Are these file formats reasonably stable and documented?
-ish. The .cproject is basically an internal dump of the managedbuild
config + some bits from cdt.core. There's a dependency hierarchy
rooted in the toolchain definition, and most the elements declare a
parent. We've found there's a certain amount of brownian motion in
the .cproject. It seems to change randomly and scanner discovery in
particular adds megabytes of useless entries. As developers find it
impossible to work with .cprojects I'm embarking on a (fool-hardy)
project to XText-ize + EMF-ize the .cproject + build model. The EMF
project makes great claims about generating all of XML / Java / UML
from a given input. Hopefully this will be easier than the
alternative of writing an adapter which maps the .cproject to some
sane human-readable output.
See also bug 226457.
Cheers,
James
