[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Managed Make Builder configurations
|
>I have some bad feelings about the "GNU executable" and "Intel C++ library".
>I would rather define at Project creation:
> * create either a Executable, a static or shared library,
Thanks for the input. I had thought of that, but was wondering how we would get different tool vendors to contribute to non-vendor specific project types. I'm wondering if the concept of "fragments" applies here. For example, Intel would provide a tool-chain fragment for the Executable project type, another fragment for the static library project type, etc...
> * decide, which target architecture to run it (x86,ARM,68k),
> * decide, which toolchain to use,
These 2 seem tied together - that is, a tool-chain supports a certain set of host platform/target platform combinations. But, from the UI perspective, we could have the user first pick the target platform and then filter the choice of tool-chains based upon it.
> * decide, which additional files I need (like startup code).
>
>On which architecture the Toolchain is run, though the development host, is
>determined by the Eclipse OS/Arch anyway.
>What I miss in the managed build is a place to enter path-settings about the
>toolchain and the tools. Though, I can get rid of adding several toolchains
>to my PATH settings with all the hazzles and instead have Eclipse/CDT do
>that, for each project at the point where it needs it (Build Console,
>Run/Debug).
Ideally, I think a tool-chain should be able to tell the managed build system what directories to add to PATH, LIB, INCLUDE. This can work on Windows because a typical installation will add information to the system registry about where the product was installed and the tool-chain could query the registry at run-time. I don't know if Linux has any similar capabilities.
>What I also think of is, like the cleanCommand, why this isn't set as tool?
Could you re-phrase this question? I'm not sure what you mean.
Regards,
Leo
-----Original Message-----
From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On Behalf Of Henning Riedel
Sent: Thursday, June 10, 2004 2:58 PM
To: cdt-dev@xxxxxxxxxxx
Cc: cdt-dev@xxxxxxxxxxx
Subject: 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.
I have some bad feelings about the "GNU executable" and "Intel C++ library".
I would rather define at Project creation:
* create either a Executable, a static or shared library,
* decide, which target architecture to run it (x86,ARM,68k),
* decide, which toolchain to use,
* decide, which additional files I need (like startup code).
On which architecture the Toolchain is run, though the development host, is
determined by the Eclipse OS/Arch anyway.
What I miss in the managed build is a place to enter path-settings about the
toolchain and the tools. Though, I can get rid of adding several toolchains
to my PATH settings with all the hazzles and instead have Eclipse/CDT do
that, for each project at the point where it needs it (Build Console,
Run/Debug).
What I also think of is, like the cleanCommand, why this isn't set as tool?
> > 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
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev
>
--
+++ Jetzt WLAN-Router für alle DSL-Einsteiger und Wechsler +++
GMX DSL-Powertarife zudem 3 Monate gratis* http://www.gmx.net/dsl
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev
