[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Build System redo
|
On 2015-03-17 20:14, Marc-André Laperle wrote:
Hi Doug,
I agree with pretty much all of what you said. I think it's important to
keep the ability to change all the build settings from the UI so that
the user does not have to write build files, just like you mentioned in
the last point. For people who don't know, it's currently possible to
have a project that generates Makefiles for you based on the build
settings changed in the UI and the build is executed externally using
make. I think the idea of generating files and delegating to an external
builder is good enough so that we don't need an internal builder. I have
to admit that I'm not an expert of the current MBS/CDT 4.0 build system
but I'm not sure how much of the complexity come from the fact that
there is an internal builder or the fact that there are "managed" build
settings. Most of the things you specify in plugin.xml are about build
settings which are needed regardless of whether the build is done
internally of generating Makefiles (correct me if I'm wrong!). Ideally,
all the builders and compilers would have nice APIs that would describe
options, build setups, tools, etc but I don't know how close we are to
that (Boost.build API?).
From my perspective, I am going through old code and removing very old
things (starting with the UI) and slowly getting a better understanding.
One concern that I had was about workspace backward compatibility. Do we
want to support importing old (pre MBS/CDT 4.0) projects? I think we'd
probably want to still support importing MBS/CDT 4.0 projects.
Marc-Andre
My dream-scenario would be one where the entire build model (options and
their interrelationsships, source files, include paths, how to build,
etc.) was managed through a well defined remote API (over websockets or
whatever) such that the actual implementation of the build model was
pluggable and possible to implement even outside Eclipse. Both the
"Boosting CDT Build" talk and the "Eclipse + Gradle" talk at EclipseCon
suggested solutions along these lines.
Such an architecture would, for example, be extremely helpful in getting
CDT work well in places where not all developers are using the same IDE.
--
*Jesper Eskilson* /Development Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
E-mail: jesper.eskilson@xxxxxxx <mailto:jesper.eskilson@xxxxxxx>
Website: www.iar.com
<http://www.iar.com> Twitter: www.twitter.com/iarsystems
<http://www.twitter.com/iarsystems>
