RE: [cdt-dev] One more question about Managed builder

[Sean Evoy <sevoy@xxxxxxxxxx>]

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