Hi Doug,
> Right now, I have separate
default configurations for each version.
That is the way it is intended to work,
although it would be nice if you could change the tool chain of an existing
configuration (other than via a conversion).
> We actually have a
front end tool that calls the appropriate version based on a flag which
I’ve defined as an option.
With separate
configurations, you could set the flag appropriately in the configuration
definition, and use the option “applicability” support to not
display the option in the UI.
If you really want to use
the multi-version support, that is, if you have a succession of versions, and
not, for example, versions that support the same set of options, but different
platforms, you could add version numbers to your tool-chain ids. Then
there is additional support you can get, for example, deciding when users must
upgrade old projects to a new version and providing a converter to do that
automatically. See the ToolChain attributes versionsSupported and
convertToId, and the documentation on converters.
Regards,
Leo
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent: Monday, May 29, 2006 9:56 PM
To: CDT
General developers list.
Subject: RE: [cdt-dev] MBS
Question
Thanks, Leo,
I guess my main question
with the multi-version support is how does it manifest itself in the UI. That
is, how does the user select which version of the tool chain to use. Right now,
I have separate default configurations for each version. We actually have a
front end tool that calls the appropriate version based on a flag which
I’ve defined as an option. I have subclassed the tool to handle the
different behaviour in the versions.
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Treggiari,
Leo
Sent: Monday, May 29, 2006 9:03 PM
To: CDT
General developers list.
Subject: RE: [cdt-dev] MBS
Question
The multi-version support
is intended to support a known set of versions - for example a 1.0 version of a
tool chain and a 2.0 version. Both versions can be installed on a machine
and different configurations can be created that use the different versions.
A converter can also be supplied for when a user wants to update
configurations that use the 1.0 tool chain to use the 2.0 tool chain.
Typically the 1.0 and 2.0 tool chains might support a different set of
options. The different versions can also implement a configuration
environment provider to properly set up the build environment (paths) for the
different versions.
To answer your question
Doug, yes, isToolChainSupported is intended to be implemented by a tool
integration that can tell whether or not the tool chain it supports is
installed.
Leo
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent: Monday, May 29, 2006 4:32 PM
To: CDT
General developers list.
Subject: RE: [cdt-dev] MBS
Question
Thanks guys. I
had a feeling this would be difficult. And it actually points out that I should
be enumerating the versions that I support and make sure that the options are
appropriately defined for those versions. I can use isToolChainSupported to
make sure I have that version installed, which I assume is the way it was
intended to work J.
Thanks again!
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Sennikovsky,
Mikhail
Sent: Monday, May 29, 2006 1:24 PM
To: CDT General
developers list.
Subject: RE: [cdt-dev] MBS
Question
Hi Leo,
Correct
me if I’m wrong, but it seems that the current multi version support does
not provide the capability for dynamic calculation of the tool-chains really
installed on the system. But what it does is allows converting from one
tool-chain to another based upon the converter info defined without taking into
account whether or not the tool-chain is installed on the system or not.
Mikhail
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Treggiari,
Leo
Sent: Monday, May 29, 2006 9:07 PM
To: CDT
General developers list.
Subject: RE: [cdt-dev] MBS
Question
Hi Doug,
I
can’t remember anyone trying to implement a dynamic list of enumerated
options, but it probably can be done. The Option class has an enumList
member that contains the list of enumerated values. You could probably
modify the list after your tool-chain was loaded.
Ø
Alternatively, did we
ever add the ability for an ISV to add in a customer edit dialog for an option?
No.
Ø
We have a few different
versions of our compiler that may be installed on the user’s system at
any time.
MBS does have “multi-version” support. This is a
somewhat “heavy-weight” mechanism and is appropriate when the
versions support different options.
I also defined a “multi-instance” support a while back
(2 yrs ago?) which is lighter weight and appropriate when the versions use the
same option pages, but this has not been implemented.
Regards,
Leo
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Doug Schaefer
Sent: Monday, May 29, 2006 12:31
PM
To: CDT
General developers list.
Subject: [cdt-dev] MBS Question
Hey gang, for this
e-mail, I’ve put on my QNX software developer hat and I have a question
on MBS. And, yes, this may be a newsgroup question J,
but it is also more an ISV question.
We have a few different
versions of our compiler that may be installed on the user’s system at
any time. I know how to dynamically get the list of installed versions and I
want to present that list in a tools option on the compiler so the user can
select which version to use. Is there a way to dyanically fill out the list of
enumeration values. Alternatively, did we ever add the ability for an ISV to
add in a customer edit dialog for an option?
Thanks, and sorry for
sounding like a newbie J.
Doug Schaefer, QNX
Software Systems
Eclipse CDT Project Lead,
Tools PMC member
http://cdtdoug.blogspot.com