[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Build Model Proposal Status
|
Hi!
I agree that it comes down to someone submitting some code.
However the community must set a process for submitting such things,
especially when we are talking about big chunks of new function. Build
model is not some bug fix where you can just put a patch in the cdt-patch
list.
So what is that process? I certainly do not know.
Thanks!
-Chris
At 12:25 PM 1/13/2003 -0500, you wrote:
I guess it really comes down to whether there is commitment from the owner
of the proposal to realize the proposal in a code submission. If not,
then we really haven't made much progress.
- Doug
-----Original Message-----
From: Alain Magloire [<mailto:alain@xxxxxxx>mailto:alain@xxxxxxx]
Sent: Monday, January 13, 2003 11:50 AM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Build Model Proposal Status
>
> Well actually there are no developers working for "org.eclipse"; most or =
> all of the "committers" are at commercial companies like IBM and QNX and =
> others who have developed the features and decided to make them open =
> under CPL so everyone can use them. Although contributing code isn't =
> required like with the GPL it's still a good idea because if everyone =
> does that, it's like having thousands of free developers working on your =
> product. And as it says here:
>
>
<http://www.eclipse.org/tools/team-leaders.html=20>http://www.eclipse.org/tools/team-leaders.html=20
>
> "The Eclipse Tools Project is a meritocracy. The more you contribute the =
> more responsibility you will earn." So although I'm not a committer yet =
> and I can't speak for the current ones, as a user of CDT I encourage you =
> and others to contribute what you've done back to the community so we =
> can all benefit from our collective knowledge and experience. Just my =
> opinion. Thx.
8-)
They were some propositions for the build, but none were carry through.
The QNX team working on the CDT, refocus our limited resources on the
debugger and getting the overall CDT(build, indexer, model , ... etc) in
to a better(more usable) shape.
Some important areas need work:
(1) Build
(2) indexer
(3) model/parser
(4) launch/Target(remote)
(5) The debug side of things is slowly but surely getting better
For the build:
- it is important to have an interface(contract)
* to let the other modules retrieve information.
* for other build models to work nicely
- error parsers, extension points
- persistency for markers
- and a default implementation (CDT) (makefile, ant etc ...)
including UI views.
I'm ready to work with anyone having the time to take the lead on this.
Since many areas in Eclipse(Resource/Workspace) are going through some
changes(2.0.x, 2.1, 2.2), the first implementation can be simple and improve
through iterations.
If not, I can revive some code(based on an earlier build model proposition in
september), to serve as a template.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
<http://dev.eclipse.org/mailman/listinfo/cdt-dev>http://dev.eclipse.org/mailman/listinfo/cdt-dev
