Skip to main content

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

> 
> JDT has a built-in Java compiler. I'm not suggesting that for CDT - I don't
> think it is possible since there is no common binary output. What I have in
> mind is a C builder preference page that gives the external commands and
> options for building and linking. For example, it might say to compile a C
> file into an object file you use the command "cc -c ${sourcefilename} -o
> ${objectfilename}". Plus maybe a combo box that would switch all the
> settings between gnu, visual studio, K&R C, etc. (and probably a way to save
> a custom configuration/target).
> 

Why not go one step higher define an interface, that contains the actions/methods
that are common or needed, lets make it very simple to begin with

IBuilder {
  buid();
  getIncludePaths();
...
}

Then let the implementations, GNU, Visual Studio, etc ... provide
the implementation with UI's and extension that would not be possible in
others.


> When a source file changes, it's easy to recompile the source and then
> relink. When you change a header file, well that's a little harder. For each
> source file the code would have to automatically maintain a list of headers
> it depends on, and then when one of the headers changes it would rebuild all
> the sources that include it. I've used systems that didn't do this and it
> was not ideal but ok because I could do a full rebuild if I wanted. I've
> also used systems that *do* do this and occasionally they get it wrong so I
> don't 100% trust it - first odd bug I see I rebuild everything and see if
> that helps and it often does. So I'm not convinced header file dependencies
> have to be handled for it to be useful.
> 
> There are many small-ish types of projects where a make or ant file is
> overkill and having to generate one (by hand or by command) wastes time. So
> I think having the capability to build without one would make the easy cases
> easier, while still making the hard cases possible.

100% with lets start with easier case and deal with the complexity later.

My point here is to provide the interfaces, to let the possibility to provide
a different implementation.

> 



Back to the top