[
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...
I think, I missed one thing. I sometimes like the feature of other IDEs,
where you first choose from a given set of predefined things, like "Write a
wxWindows App", "Write a Win32 Console App"...
When thinking about this, I can imagine using an rather abstract project
description, with predefined templates for automatic code generation and
basic setup of a skeleton project of this type.
Underneath this more abstract project, we could define the type (exe,so,a)
and so on.
This would leave room for company rules on project/code layout generators,
lint tools to use, 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.
Well, I could have an embedded target, and might have several compilers for
it. But later I could decide to go over to another architecture with
(almost) the same codebase. Though, I don't like to create a totally new
project and create the library with 30 files twice just because I have some
#ifdef's within the code (or have architecture directories) with about 1 or
2 different arch-specific files.
The difference also lies within the target-arch, the target will run on vs.
the arhitecture, the toolchain runs on.
> > * 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.
Well, I see clean command also as part of the toolchain. This could be a
simple call to 'del /S', or a 'rm -rf' but also a call to a
cleanup-shellscript. But I lately had some problems e.g. with the MinGW
Targets, where neither 'del' worked nor 'rm -rf'. I must confess I have
several toolchains installed here, starting with cygwin, MinGW/MSYS, and
another cross-compiler for 68k, ... though I personally would be happy to
have path settings setup within eclipse rather than relying on shuffling the
PATH settings in Windows. I also sometimes have problems on using some older
cygwin-toolchains which depend on different cygwin1.dlls.
Maybe one could add something like an ordered toolchain description
<project><startupBuildTool>oec.managed.tool.builder</...> would setup the
builders and the following toolchain-tools and -paths.
<tool id="makebuilder"><command name="make" path="toolchain.mingw.path"/>...
<tool id="cleantool"><command name="rm -rf"
path="toolchain.mingw.msys.path"/>...
Something like this. And before calling the Build/Run-consoles, the plugin
could add the toolchain-paths to ENV.
> 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
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev
>
--
"Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen!
Jetzt aktivieren unter http://www.gmx.net/info
