RE: [cdt-dev] Build Model Enhancements for CDT 8.0

["Treggiari, Leo" <leo.treggiari@xxxxxxxxx>]

Hi Doug,

I must not have explained myself well.  I'll use the term "MBS" for the current
"Managed Builder for Make".

We have "standard" build which I would explain as:
-  Give CDT a build command line to invoke
-  Set up everything else yourself:
   -  Set up build environment, "scanner discovery", error parsers, binary parser, etc
      These currently have gcc and make defaults
-  Some support for selecting a make target?

We have MBS which I would explain as:
-  A tool integrator declares his tool-chains in XML and implements a few Java interfaces
-  MBS:
   -  Provides property pages with individual tool options and other build settings
   -  Given the tool-chain definition and the user settings on the property pages,
      sets up everything for the build
   -  These currently have gcc and make defaults
      -  Setting up to use a different tool-chain is well supported (but not easy)
      -  Setting up for a different builder is not well supported

You said, "My objective is to be able to enable other "managed" build systems to 
be first class citizens in the CDT's build"

I think this a great idea and was commenting on that.

Here are a few random thoughts which require much more detail:
-  What are the characteristics of a "managed builder"?
   -  It defines some sort of "project file" or "config" file that specifies build 
      information specific to a particular project. The point I was making in my
      previous reply is that a "managed builder" may want to provide a series
      of "forms" that allow the user to "edit" the project information in a GUI
      rather than by editing the text file directly.  These "forms" are specific
      to the "managed builder", providing a higher level UI for specifying the
      information in the project/config file.  Providing these "forms" should
      be optional but well supported when desired.
   -  It may have its own concept of a tool-chain definition.  I know that Qt-Creator
      does.  How does the CDT "project model" get information that is useful from
      those definitions - i.e. so that the use does not need to provide it again?
-  What information does the CDT "core build system" need in order to make using
   any of these managed builders a seamless experience?  Our goal for a 
   "managed builder" is that it should be as easy to use as it is in an
   IDE created specifically for using that builder - e.g. Qt Creator and Qmake.
-  MBS should morph into being one of the "managed builders".
-  I think some of the MBS core "model" and ideas should be considered for
   the core, "managed builder" model.

Regarding what is the "project model", I see the "project model" as the in-memory 
representation of the CDT project file, e.g.
   -  What files are in the project
   -  What configurations are defined
   -  All of the information required to do a build of each configuration
   The rest of CDT (outside of the project model) supports the editing of the 
   project model, debugging, etc

Thanks,
Leo

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent: Sunday, August 01, 2010 10:19 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Build Model Enhancements for CDT 8.0

On Sun, Aug 1, 2010 at 12:48 PM, Treggiari, Leo <leo.treggiari@xxxxxxxxx> wrote:
>> I do not plan on using the managed build model for the other "managed
>> build systems". They usually have their own system for specifying
>> tools and options, such as CMake's CMakeLists.txt file, and qmake's
>> .pro project files. It probably make more sense to have good editors
>> for those files than manage these settings in the properties pages.
>
> For the current MBS, the property pages provide a simpler UI for specifying
> the information necessary to create the make file (or for the internal
> builder).  Wouldn't you want to allow the same capability for other
> managed builders - i.e. the ability to provide property pages as an
> alternative to directly editing the "project files".  For example, in
> Qt Creator, the .pro file can be managed from the UI - if I remember
> correctly.  Ideally, you would provide a UI for specifying the
> project/build information that does not require a user to understand the
> project file format, plus the ability to edit the project file directly
> and automatically keep them "in-sync".

Managed build does hide the gory details of the build and for many
users, its great. This is not about replacing managed build. It's
about enhancing our "standard" build support to take into account
these other external managed build systems. We need to be selective
about what automations and what UI we provide for these to make sure
the workflows aren't foreign to them, as is the "standard" build
philosophy. I'm not saying do none. I do want the CDT to add value
into these environments. But hiding them behind managed build would
not be a good choice.

>
> Leo
>
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
> Sent: Saturday, July 31, 2010 7:54 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Build Model Enhancements for CDT 8.0
>
> On Sat, Jul 31, 2010 at 10:30 PM, Austin Morgan
> <admorgan@xxxxxxxxxxxxxxxxxxx> wrote:
>> On Sat, Jul 31, 2010 at 10:15:04PM -0400, Doug Schaefer wrote:
>>> Hey gang,
>>>
>>> I've started an enhancement request for changes I'd like to make to
>>> the Build Model, not the managed build model, but the build stuff in
>>> the project model. My objective is to be able to enable other
>>> "managed" build systems to be first class citizens in the CDT's build
>> <snip...>
>>
>> In reading the documentation of CDT I was under the impression that the
>> managed build model was superseding the Build Model.  If not can
>> someone point me to the documentation?  I think it might help me with a
>> project I am currently working on.
>
> Well, it's a complicated subject. In the beginning we had the Managed
> Build Model, things like IConfiguration, ITool, IOption and friends.
> We often just shortened it to Build Model when discussing it in the
> early days but at the end of the day, my claim is that this model is
> really specific to managed build.
>
> A couple of years ago we attempted to bring some of those concepts
> into the CDT core and that is what is called the Project model, which
> is not to be confused with the CModel which is what you see in the
> Outline view. I hate the name Project model since outside of Build,
> I'm not sure what it's used for.
>
> So what I mention here is really updating the Project/Build model. The
> Managed Build model extends the Project/Build model somehow which I
> still find mysterious. But the managed build model is used by CDT's
> managed build system which includes an internal builder and a makefile
> generator that use this model.
>
> I do not plan on using the managed build model for the other "managed
> build systems". They usually have their own system for specifying
> tools and options, such as CMake's CMakeLists.txt file, and qmake's
> .pro project files. It probably make more sense to have good editors
> for those files than manage these settings in the properties pages.
>
> Doug.
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev