[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] One more question about Managed builder
|
>-----Original Message-----
>From: Alex Chapiro [mailto:achapiro@xxxxxxx]
>Sent: April 14, 2004 12:59 PM
>To: cdt-dev@xxxxxxxxxxx
>Subject: Re: [cdt-dev] One more question about Managed builder
>
>
>I want to clarify my position. I do not expect that all the issues I
>wrote about should be immediately implemented in CDT. I'm just
>advocating simplification of managed builder customization.
We are also looking for specific guidance on "great idea, lets see
an implementation, it should probably look something like this" so that
we can also pro-actively contribute.
Right now we are in the migration stage from an existing managed make
solution ... hence all of the questions. These are functionalities we
are willing to help develop and focus on.
Thanks,
Thomas
>Recoskie, Chris wrote:
>
>>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
>>
>>.
>>
>>
>>
>_______________________________________________
>cdt-dev mailing list
>cdt-dev@xxxxxxxxxxx
>http://dev.eclipse.org/mailman/listinfo/cdt-dev
>
