Since there are so many people, including
myself, with wish lists right now (fully expressed and captured, or otherwise),
I think it would be worthwhile for those of us that are interested to make a
point in the coming weeks to put everything forward in a somewhat organized
manner. That way some coherent plans can be hatched regarding the changes
(e.g. what to implement, how, when, etc.).
Right now we’re all just lobbing
semi-random feedback at Sean via the list, and I am guessing he would probably
appreciate it if we were a little more organized about it :-)
I guess the best way for us to go about
this is to do the usual thing and capture our wishes in discrete Bugzilla
entries (massive catch-all entries listing everything we want are not useful)
so they can be tracked, and then with time some sort of feature spec and plan
document(s) can be created.
Or should we spam our wishlists to the dev
lists and then one person captures them in Bugzilla so that we don’t end
up with a whole bunch of duplicate info?
I know this probably seems like a bunch of
work, but personally I’m having a hard time keeping straight who wants
what changes and why, and how that intersects with Sean’s plans and my
own wishlists. I also have the feeling that there are plenty of hidden requirements
that people have but haven’t put forth yet, which are either going to be
missed or are going to pop up later as “gotchas”.
Sean, what do you think?
___________________________________________
Chris Recoskie
Texas Instruments, Toronto
-----Original Message-----
From: cdt-dev-admin@xxxxxxxxxxx
[mailto:cdt-dev-admin@xxxxxxxxxxx] On Behalf
Of Sean Evoy
Sent: Wednesday, April 14, 2004
11:00 AM
To: cdt-dev@xxxxxxxxxxx
Subject: RE: [cdt-dev] One more
question about Managed builder
Precisely.
You
create a list for static libs and one for dynamic. The static list control has
the command '-Bstatic -l' and it prepends this to every element in the list
when asked for the option contents. The downside to this approach is that the
command line looks like -Bstatic -llib1 -Bstatic -llib2, but I suspect that
-Bstatic -llib1 -llib2 is just syntactic sugar for that command anyway.
I
am not averse to a custom option, or allowing implementers to optionally define
a custom UI element for a default option type, I just want to keep the number
of option types under control, and I want to try as much as possible to
maintain a design that allows people to implement a toolchain with little or no
Java coding. Having discussed this with Jeremiah, Leo, and to some extent,
Chris, I now think that a basic toolchain should be implementable without Java,
but that this design principle should be relaxed for advanced build model
elements.
Sean
Evoy
Rational Software - IBM Software Group
Ottawa, Ontario, Canada
|
"Recoskie, Chris"
<crecoskie@xxxxxx>
Sent
by: cdt-dev-admin@xxxxxxxxxxx
04/14/2004 10:07 AM
|
Please
respond to
cdt-dev
|
|
|
To
|
<cdt-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
|
RE: [cdt-dev] One more question about Managed
builder
|
|
I
think the idea Sean is proposing is to have two separate list
controls; one for the static libs, and one
for the dynamic libs. You
would specify the linkage type just by putting the
library in the
appropriate list.
___________________________________________
Chris Recoskie
Software Designer
IDE Frameworks Group
Texas Instruments, Toronto
> -----Original Message-----
> From: cdt-dev-admin@xxxxxxxxxxx
[mailto:cdt-dev-admin@xxxxxxxxxxx] On
> Behalf Of Alex Chapiro
> Sent: Wednesday, April 14, 2004 10:11 AM
> To: cdt-dev@xxxxxxxxxxx
> Subject: Re: [cdt-dev] One more question
about Managed builder
>
> The main problem is that customer should
avoid editing of generated
make
> file (and I like it!). It means that all
possible options (those you
> know now and those you don't know yet :-))
can be constructed using
> existing UI. It seems to me unrealistic.
> BTW, as far as I'm concerned, list
control also doesn't help a lot
for
> discussed case. I don't see any way to
specify linkage type for each
of
> the list elements.
>
> Sean Evoy wrote:
>
> >Alex,
> >I don't think any of the existing option
types will output the line
you
> >are looking for. The list option probably
comes the closest, since it
> >will always append a specified prefix to
each element it contains.
That
> >said, it seems as though you want a
pre-prefix, like
-B<static|dynamic>,
> >followed by the contents of the list. The
string option now allows
you
> >to specify
> >
> >Could you live with the prefix for each
item being -Bstatic -l, so
that
> >the output would be -Bstatic -llib1
-Bstatic -llib2 ... -Bdynamic
-llibN
> >...? If so, then a list control will work
for you.
> >
> >We could add a custom option type that a
toolchain implementer could
> >define, but before we take that route, I
want to make sure there is
no
> >other way to solve the problem. As
a design principle, I do not want
to
> >see an explosion of option types to
handle every possible output
case.
> >It will make it hard to support the build
model going forward and
there
> >is a UI component to consider as well.
Currently, the UI builds
itself
> >based on the option description. String
options are displayed in an
> >entry field, list options in a
ListControl, and so on. If we do
> >introduce a custom option, then the
implementer of that option is
going
> >to have to supply the UI element
(FieldEditor) that represents the
> >contents in the option graphically.
> >
> >I could live with that with some
reservations, not the least of which
is
> >that we surrender some control over the
UI look-and-feel to the
> >implementer of the custom option. Of
course, this type of option is
> >likely to appear only in a commercial
product so the implementer will
> >have a strong incentive to test properly.
My other concern is that it
> >forces the implementer to write Java
code, but again, only advanced
> >users would take advantage of this and
you can (theoretically)
implement
> >a toolchain without using a custom
option.
> >
> >Sean Evoy
> >Rational Software - IBM Software Group
> >Ottawa, Ontario, Canada
> >
> >
> >
> >
> >Alex Chapiro <achapiro@xxxxxxx>
> >Sent by: cdt-dev-admin@xxxxxxxxxxx
> >
> >
> >04/13/2004 06:09 PM
> >
> >
> >Please respond to
> >cdt-dev
> >
> >
> >To
> >cdt-dev@xxxxxxxxxxx
> >
> >cc
> >
> >Subject
> >[cdt-dev] One more question about Managed
builder
> >
> >
> >
> >
> >
> >
> >
> >I'm just looking for the method how to
define such an option as this
> >one for an import libraries list (see ld)
:
> >
> >-Bstatic -llib1 -llib2 ... -Bdynamic
-llibN ... -Bstatic ...
> >I cannot imajine anything but simple
'string' option, which is not
very
> >convinient.
> >If I don't miss something, I think this
is one more argument for
> >existing of custom option categories.
> >
> >
> >
> >
>
>_______________________________________________
> >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
