| Re: [cdt-dev] Build System redo |
On 2015-03-20 04:48, Alena Laskavaia wrote:
As much as I hate internal builder it is simple and it works out of the
box. We still
have to have external toolchain but at least it does not force to have
external build system as well.
Remember - we cannot ship it with CDT (unless it is eclipse project or
it has to go though some complicated approval process), means user has
to deal with installing it as well.
Sounds like something to use Oomph for. Couldn't the CDT product setup take care of installing it? That way nothing needs to be "shipped" with CDT.
If they do want to have external build system - great, we should just
provide some out of the box
integration to hook it up (i.e. make, cmake, qmake, vs, etc).
Of cause if they do use gcc toolchain they likely have make as well and
we can use it by default,
but as you mentioned in your presentation at eclipse con - make is not
good for IDE integration (as a matter of fact
it is worst of all of other systems people mentioned). The only way I
see us using make if we generate hidden
makefiles (i.e. not stored with project), so people cannot possibly be
tempted to modify it and do all configuration
using our UI.
Btw what license is boost.build is under?
On Thu, Mar 19, 2015 at 6:52 PM, Vladimir Prus
<vladimir@xxxxxxxxxxxxxxxx <mailto:vladimir@codesourcery.com>> wrote:
Alena,
looking at that page, it seems like the proposal is to still have
CDT have it's own way to describe
build, but instead of using .cproject with its XML use a plain text
file. I wonder why we really
need to reinvent build systems? This space has multiple solutions,
so why CDT, who does not have
excess amount of contributors, be in position to create something
better than all the other
options?
Why not focus instead, exclusively, on using external build systems?
On 03/19/2015 11:55 PM, Alena Laskavaia wrote:
I started a wiki page here
https://wiki.eclipse.org/CDT/__ProjectsAndBuildWorkingGroup
<https://wiki.eclipse.org/CDT/ProjectsAndBuildWorkingGroup>
feel free to edit it
On Thu, Mar 19, 2015 at 3:43 PM, Martin Runge
<martin.runge@xxxxxx <mailto:martin.runge@xxxxxx>_________________________________________________<mailto:martin.runge@xxxxxx <mailto:martin.runge@xxxxxx>>> wrote:
Hi all,
I am trying to write a CMake plugin for CDT (see bug
350206, got stuck but
still working on it). So my perspective is influenced by
external build
systems like CMake.
I fully agree with idea of the "portable build model" (I
also know it as
"project model"). This is somthing that is implemented very
nicely in CMake,
but also qmake ,boost.build and the autotools.
Project model is the file "CMakeLists.txt" (under version
control).
(Cross-)Compiler for the target platform is defined in a
"toolchain file"
outside of the project model (included with cmake
distribution or an own one).
Similar: qmake ->project model in .pro file; compiler
settings in mksepcs,
autotools -> project model in Makefile.am, toolchain
selected during configure
run via --target=arm-linux-gcc)
These build systems share a property which was not
mentioned in this
discussion yet: there is a "configure" step involved in the
build. Needed only
once to select the toolchain, find external libraries and
include paths, but
not for every build during development.
The indexer cannot know the include paths before the
configure step was run.
But it would be nice to be able to navigate through the
sources without having
to build them before, especially for large projects.
I would really like to see better support for the
"configure" step.
best regards
Martin
Am Donnerstag, 19. März 2015, 16:31:40 schrieb Jesper Eskilson:
> By "portable" I mean having a CDT project which can be
checked out and
> built on both Windows and Linux (for example) without
having to make any
> changes to the project, just as you can do with Java
projects. I
> understand that it is most likely not easy to do, though.
>
> /Jesper
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>
<mailto:cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/__mailman/listinfo/cdt-dev
<https://dev.eclipse.org/mailman/listinfo/cdt-dev>
_________________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/__mailman/listinfo/cdt-dev
<https://dev.eclipse.org/mailman/listinfo/cdt-dev>
--
Vladimir Prus
CodeSourcery / Mentor Embedded
http://www.mentor.com/__embedded-software/
<http://www.mentor.com/embedded-software/>
_________________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/__mailman/listinfo/cdt-dev
<https://dev.eclipse.org/mailman/listinfo/cdt-dev>
--
*Jesper Eskilson* /Development Engineer/
IAR Systems AB
Box 23051, Strandbodgatan 1
SE-750 23 Uppsala, SWEDEN
E-mail: jesper.eskilson@xxxxxxx <mailto:jesper.eskilson@iar.com>
Website: www.iar.com
<http://www.iar.com> Twitter: www.twitter.com/iarsystems
<http://www.twitter.com/iarsystems>_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev