[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Managed Make Builder configurations
|
> 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.
> 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?
Yes it does. But notice that I have added a targetPlatform element as
the child of a toolChain element. The targetPlatform element would have
attributes that describe the platform on which the build artifact runs.
Two of these attributes could be osList and archList.
> Just curious: is defaultExtension important to keep it separately from
> the artifact name? Or this is just for compatibility?
Just for compatibility.
> 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?
> 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>.
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
