[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] New build paradigms
|
Hi!
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.)
Thanks!
-Chris
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
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev
