Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Managed Make Builder configurations

Sorry Lads,
I'm not avoiding the conversation on purpose, I just have a fair amount of bugs to get squared away before I start discussing the future shape of the managed build system with all of you.

Sean Evoy
Rational Software - IBM Software Group
Ottawa, Ontario, Canada


"Treggiari, Leo" <leo.treggiari@xxxxxxxxx>
Sent by: cdt-dev-admin@xxxxxxxxxxx

06/10/2004 05:12 PM

Please respond to
cdt-dev
To
<cdt-dev@xxxxxxxxxxx>
cc
Subject
RE: [cdt-dev] Managed Make Builder configurations





> I was wondering is make target type (executable/binay/archive) so
> essential attribute to use it on the top of the model hierachy?

It seems that there is no consensus regarding what is at the top of the
model.  We'll need to have more discussions on this - with Sean involved
too!

> It useful if I'd like to replace automatically generated property page

> to the custom one
> As a compromise: create this tag on both levels (option and
optionCategory)

I misunderstood what you want.  My "custom editors" are for individual
property values, for example, some sort of font picker dialog box.  I
agree that both are needed.

Leo

-----Original Message-----
From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On
Behalf Of Alex Chapiro
Sent: Thursday, June 10, 2004 3:53 PM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Managed Make Builder configurations



Treggiari, Leo wrote:

>>What is the meaning of projectType tag? Is it the same as abstract
>>target now?
>>    
>>
>
>No.  I see projectType as describing the generic type of project that
>the user wants to create, for example, a GNU executable vs. an Intel
C++
>library, etc.  The target today specifies that information, but also
>specifies additional information that I think belongs in child elements
>that can be specified multiple times.  For example, the tool-chain that
>creates a GNU executable on Linux IA32 and the tool-chain that creates
a
>GNU executable on Windows Itanium could be two tool-chain children of
>the GNU executable projectType.
>  
>
As soon as I remove "executable", "library" from projectType
description, I get an abstract target in the current model.
I was wondering is make target type (executable/binay/archive) so
essential attribute to use it on the top of the model hierachy?
It looks rather as a candidate for configuration attribute (later about
that). I mean something like that:

Example of configuration:
   Project Type = GNU
   target architecture = X86
   make target type = Shared Object

I understand that there is one inconvinient thing: set of tools can be
different for different make target types (for example, gcc + ar for *.a

and
gcc + gcc (ld) for *.so).  On the other hand how it is implemented now
1) Causes duplication of configurations. For example now in QNX IDE we
have 6 different make target types. Would we use more than one tool
chain, we should duplicate these 6 configuration for each of them
2) There is no way now to change make target type for existing MMB
project. Why I cannot change .so project to .a project?

>>What do you think about the following little schema extension (this is
>>    
>>
>>once again about configuration attributes :-) )?
>>    
>>
>
>I don't understand the purpose of your configuration children,
><attribute> and <attribValue>.  Could you explain them so more?
>
>  
>
That's my point. I want to parametrize configuration depends on
projectType, using your terminology. For example, when I create
configuration for GNU toolchain to build executable for armle target, I
would like to select these options from the configuration dialog. So
<attribute> is description of configuration parameter. In my example:
CNU ->
 parameters:
   target architecture; options: x86/armle/armbe
    binary type; options: exec/so/a/...

or

VC ->
 parameters:
     binary type; options : exe/dll/lib

>>As long as we are talking now about schema, I'm also advocating for
>>small modifiction of optionCategory tag:
>>
>>       <optionCategory
>>              owner="...."
>>              name="...."
>>              id="...."
>>           *   /class="....">/  *            
>>        </optionCategory>
>>
>>to make it possible to provide customized option editors.
>>    
>>
>
>I want custom editors also, but I think the attribute belongs on the
><option> element, not the <optionCategory> element.  The
><optionCategory> element is for grouping options in the property page
(I
>think...).  Also, I'd suggest a more descriptive name, e.g.
editorClass,
>because there are other attributes that use a Java interface that I
want
>to add to <option>.
>  
>
It useful if I'd like to replace automatically generated property page
to the custom one
As a compromise: create this tag on both levels (option and
optionCategory)

>Leo
>
>-----Original Message-----
>From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On
>Behalf Of Alex Chapiro
>Sent: Thursday, June 10, 2004 9:30 AM
>To: cdt-dev@xxxxxxxxxxx
>Subject: Re: [cdt-dev] Managed Make Builder configurations
>
>Looks good.
>Just a couple of questions
>
>What is the meaning of projectType tag? Is it the same as abstract
>target now?
>
>toolchain->archList exists in current model. But it works as a host
>toolchain filter and does nothing with target (sorry!) architecture.
>Does it have the same meaning in your model?
>
>Just curious: is defaultExtension important to keep it separately from
>the artifact name? Or this is just for compatibility?
>
>What do you think about the following little schema extension (this is
>once again about configuration attributes :-) )?
>
><projectType>
>    <toolChain>
>                 ....
>    </toolChain>
>    <configuration>
>                 ....
>        <!-- List of configuration attributes (target CPU, binary type>ect.) -->
>                 <attribute
>                     name="..."  
>            id="..." >
>            <!-- Attribute is alvays enumerated type (?). Its>description includes the list>             of possible values and how each value impacts toolchaun>element; this is already >             exists on configuration level -->                  
>                     <attribValue
>                         name="..."
>                id="..." >
>                         <toolReference
>                  id="...">
>                                     <optionReference
>                        defaultValue="..."
>                        id="...">
>                     </optionReference>
>                                       ....
>                </toolReference>                
>                                  ....
>                     </attribValue>
>                     ....
>        </attribute>
>                 ....
>    </configuration>
></projectType>
>
>As long as we are talking now about schema, I'm also advocating for
>small modifiction of optionCategory tag:
>
>        <optionCategory
>               owner="...."
>               name="...."
>               id="...."
>            *   /class="....">/  *            
>         </optionCategory>
>
>to make it possible to provide customized option editors.
>
>
>Treggiari, Leo wrote:
>
>  
>
>>>Thinking more about it, isn't it what is already in the managed
build?
>>>The toolchain is the target and configuration defined in the
>>>  
>>>
>>>      
>>>
>>plugin.xml
>>
>>
>>    
>>
>>>while the build settings is the target and configuration defined in
>>>  
>>>
>>>      
>>>
>>the
>>
>>
>>    
>>
>>>.cdtbuild. Could this understanding be correct or am I missing
>>>  
>>>
>>>      
>>>
>>anything?
>>
>>
>>    
>>
>>>I guess we are missing the os and architecture. Maybe it could just
be
>>>an attribute of a target (plugin.xml definition), couldn't it?
>>>  
>>>
>>>      
>>>
>>Maybe, but I think there are 2 things wrong with the current Target:
>>
>>1.  The name - "target" is confusing as to what it represents
>>2.  It is a combination of too may concepts
>>
>>I've been working on a proposal for Managed Build functionality for
CDT
>>3.0.  I think the model needs some changes at the "top".  I'd like to
>>get rid of "target" and have the model look like:
>>
>><projectType>
>>   <toolChain>
>>       <tool>
>>           the elements under "tool" remains unchanged
>>       </tool>
>>       <targetPlatform>
>>           various target platform attributes...
>>       </targetPlatform>
>>   </toolChain>
>>   <configuration>
>>       <toolChainReference>
>>           <toolReference>
>>               the elements under "toolReference" remains unchanged
>>           </toolReference>
>>       </toolChainReference>
>>       <resourceConfiguration>
>>           <toolReference>
>>               the elements under "toolReference" remains unchanged
>>           </toolReference>
>>       </resourceConfiguration>
>>   </configuration>
>></projectType>
>>
>>The following target attributes would become projectType attributes:
>>- isAbstract
>>- parent
>>- isTest
>>The following target attributes would become configuration attributes:
>>- artifactName
>>- defaultExtension
>>- cleanCommand
>>The following target attributes would become toolChain attributes:
>>- binaryParser
>>- osList
>>- archList
>>- errorParsers
>>- makeCommand
>>- makeArguments
>>- scannerInfoCollector
>>- makefileGenerator
>>
>>I hope to have the full proposal in a week or so...
>>
>>Leo
>>
>>-----Original Message-----
>>From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On
>>Behalf Of Pierre-Alexandre Masse
>>Sent: Wednesday, June 09, 2004 7:41 PM
>>To: cdt-dev
>>Subject: RE: [cdt-dev] Managed Make Builder configurations
>>
>>
>>
>>
>>    
>>
>>>Likewise, here at TimeSys.  We currently support configurations
>>>as a combination of (build settings + toolchain).  Being able to
>>>continue to support this once we move to CDT 2.0 is important
>>>to us.
>>>  
>>>
>>>      
>>>
>>Thinking more about it, isn't it what is already in the managed build?
>>The toolchain is the target and configuration defined in the
plugin.xml
>>while the build settings is the target and configuration defined in
the
>>.cdtbuild. Could this understanding be correct or am I missing
>>    
>>
>anything?
>  
>
>>I guess we are missing the os and architecture. Maybe it could just be
>>an attribute of a target (plugin.xml definition), couldn't it?
>>
>>
>>Pierre-Alexandre
>>
>>_______________________________________________
>>cdt-dev mailing list
>>cdt-dev@xxxxxxxxxxx
>>http://dev.eclipse.org/mailman/listinfo/cdt-dev
>>_______________________________________________
>>cdt-dev mailing list
>>cdt-dev@xxxxxxxxxxx
>>http://dev.eclipse.org/mailman/listinfo/cdt-dev
>>
>>
>>
>>    
>>
>_______________________________________________
>cdt-dev mailing list
>cdt-dev@xxxxxxxxxxx
>http://dev.eclipse.org/mailman/listinfo/cdt-dev
>_______________________________________________
>cdt-dev mailing list
>cdt-dev@xxxxxxxxxxx
>http://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>  
>
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev

Back to the top