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
Software Designer
IDE Frameworks Group
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
.
