[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cdt-dev] New build paradigms
|
Hi!
No one is going to care if CDT uses make if the Makefile is
auto-generated. People just do not want to have to write their own
makefiles. I personally like make as the backbone because those same
auto-generated makefiles can serve as the batch build mechanism and folks
who have C tools tend to have make.
Thanks!
-Chris
At 02:21 PM 12/16/2002 -0500, Sebastien Marineau wrote:
One
of the things to keep in mind is that, even for option 1, there is a need
for builds to be done
outside of the IDE. This is
feedback that we have received over and over from a variety of
users and customers -- the
configuration management and build people want to build source
without the IDE (this has in
fact been a barier to the adoption of certain IDE's in the past).
So for option 1 to be useful
beyond just being a "toy", it has to tie back to build
infrastucture (make-based most
likely) that can work fully independently of the IDE.
That would suggest an approach
similar to what QNX has done for our own projects --
generated makefiles, with
intelligence in the CDT to read them in as well as
regenerate
them when settings/properties
change (this does not preclude directly invoking the tools
to do incremental builds from
the IDE).
Sebastien
-----Original
Message-----
From: Schaefer, Doug
[mailto:dschaefer@xxxxxxxxxxxx]
Sent: Monday, December 16, 2002 1:45 PM
To: 'cdt-dev@xxxxxxxxxxx'
Subject: RE: [cdt-dev] New build paradigms
I actually don't think (1) is that hard to do. Yes, you do
need to figure out the dependencies between translation units and the
header files they bring in. This information would also be
necessary to generate proper makefiles that do incremental build.
However, it shouldn't be too difficult to do. Gcc provides an
option, -M, to generate this for you and I've build a perl script in the
past to does the same. But, as Chris mentioned, the CDOM, or more
properly, the indexer, should be able record what header files a
particular file includes for a particular set of build settings.
But that will take some time to put in place.
The harder part will be building a common extensible
framework for pluging in different tools and options into the CDT
base. And I'm thinking not only compilers and linkers but other
tools as well such as parser generators, lint-like tools, etc. The
UI and builder should be able to adjust itself to these different
tools. We have some ideas here at Rational that we are trying to
put down on paper which we hope to share over the next couple of
weeks.
There are lots of examples of IDE's that do automated build
for C/C++. I can think of one major vendor that has done a great
job with UI and extensibility...
Doug Schaefer
Senior Staff Software Engineer
Rational - the software development company
Ottawa (Kanata), Ontario, Canada
-----Original Message-----
From: Ed Burnette
[mailto:Ed.Burnette@xxxxxxx]
Sent: Friday, December 13, 2002 10:49 AM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] New build paradigms
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