Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] New build paradigms


I have some questions and some comments. Questions first. How does the JDT interface with the java compiler? What is the difference between the builds that the JDT does unprompted vs. the builds it does when you save vs the builds it does when select rebuild all?

I think that 1 is hard for C/C++. In particular, the C-preprocessor makes it open season on what things change when header files change. If 1 is going to happen, it is going to come out of an amazing piece of work from the folks working on the CDOM.

Keep in mind that the CDOM is really a live IR so what they are doing is building a new C/C++ compiler front end for content that dynamically changes in a java based IDE. That's an aggressive goal. EDG makes (or made, I was last involved in a from scratch C compiler about 5 years ago) a mint selling C++ compiler front ends because they are so hard to get right. And that was for a fixed input, not a changing one. How do you deal with templates? What do you do about the preprocessor problem? C++ is not an easy language to compile. Java is a cakewalk compared to C/C++.

What does all that mean? It means that getting to 1 is, I think, a good long ways off. It's beyond 6 months for sure because it will depend on a great CDOM being in place. That the kind of thing I would expect to see earliest this time next year because it means that the CDOM has been out, matured and then used as a basis for the 1-like autobuilder.

When I think about possible build changes, I tend to think about the user experience. Here is what I would like to see:

- Graphic control of project target, and compilation/assembly and link options.
- Automatic inclusion of new source files into the build.
- Clustering of build options into named targets.
- Ability to export non-IDE buildable infrastructure for nightly batch building.

And it should be noted that what we have today needs to be preserved because it adds another key point:

- Easy import of existing projects for use with CDT.

Whether it's ant or Make under the covers should not really matter because the user should not have to be in the game of looking at the build controller at all.

As a matter of practicality cdt has a good make system now and if you couple it with a good make generation system, I think you are going to get much of the value. Today here at Tensilica we are autogenerating makefiles and it is just lovely with the make builder that is already there. We scan the project looking for source files and then create a makefile that supports the make builder. (We are working on targets and named compiler flag grouping now. e.g. release/debug/profile targets.)


At 10:48 AM 12/13/2002 -0500, Ed Burnette wrote:
I think CDT should support 3 types of builds out of the box:

1. (The default) A make-less build modeled on the JDT. CDT would know (through preferences) the commands and options needed to compile sources and link objects. Incremental builds would be done on saves. 2. Building with Ant, which would leverage all the Ant development work already going on, and 3. Building with an external Make tool. Since Make files are not as parseable and rewritable as Ant files they would have to be created by hand, mainly for legacy projects.

"Yes, Virginia, it is possible to create a software development environment which is so difficult to use that no human being can do it." - Joel Spolsky

cdt-dev mailing list

Back to the top