Re: [cdt-dev] Build System redo

[Martin.Runge@xxxxxxxxxxxxxxxxx]

Hi all,

I think about simplifying the settings presented to the user. CDT supports 
so many ways to organize a project, and every way has its settings. I 
found it hard to hide those from the user, that are unused in the current 
project.
Do you think it makes sense to spend an additional project nature to every 
build system, also the internal one?

autotools project: cnature, ccanture, autotoolsNatureV2 
CMake project:    cnature, ccnature, cmakeNature
internal builder     cnature, ccnature, internalNature
etc...

This would make it easily possible to hide property and preference pages 
of the currently unused build/project models. Curently it is hard to hide 
these settings from the user because CMake and autotools share the 
c/ccnature with the managed builder, so the managed builder settings alway 
appear. 
If there already is an easy way, I didn't it (Hints very welcome). Maybe 
this could the be simplified?

best regards 
Martin








Von:    Doug Schaefer <dschaefer@xxxxxxx>
An:     Vladimir Prus <cdt-dev@xxxxxxxxxxx>, "cdt-dev@xxxxxxxxxxx" 
<cdt-dev@xxxxxxxxxxx>, 
Datum:  2015-03-20 03:59
Betreff:        Re: [cdt-dev] Build System redo
Gesendet von:   cdt-dev-bounces@xxxxxxxxxxx



Again, it is still a requirement that we provide an environment that the 
VS and Xcode users will be comfortable with. Not sure I like the idea of 
forcing them to learn how to write build files. It's one thing our current 
build system does well for many. Taking it out would be a huge step 
backwards.

Sent from my BlackBerry 10 smartphone on the Rogers network.
  Original Message
From: Vladimir Prus
Sent: Thursday, March 19, 2015 6:52 PM
To: cdt-dev@xxxxxxxxxxx
Reply To: CDT General developers list.
Subject: Re: [cdt-dev] Build System redo


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
>
> feel free to edit it
>
> On Thu, Mar 19, 2015 at 3:43 PM, Martin Runge <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>
>     To change your delivery options, retrieve your password, or 
unsubscribe from this list, visit
>     https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
>
>
> _______________________________________________
> 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
>


--
Vladimir Prus
CodeSourcery / Mentor Embedded
http://www.mentor.com/embedded-software/
_______________________________________________
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
_______________________________________________
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