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
