Re: [cdt-dev] Managed builder questions

[Sean Evoy <sevoy@xxxxxxxxxx>]

Alex,
That's a lot of questions. See my coffee-fueled
comments in-line.

Sean Evoy
Rational Software - IBM Software Group
Ottawa, Ontario, Canada

Alex Chapiro <achapiro@xxxxxxx>
Sent by: cdt-dev-admin@xxxxxxxxxxx

04/12/2004 04:14 PM

Please respond to
cdt-dev

To	cdt-dev@xxxxxxxxxxx
cc
Subject	[cdt-dev] Managed builder questions

We in QNX decided to adapt managed build solution to our C/C++ tool set.
Doing this work, I'm trying to figure out how to implement some features
using managed builder .


1) Pre- and post-build actions. In theory I can add something very 
generic to the tool chain. However being added to tool chain 
description, this element becomes a mandatory step, and there is no way
to disable it. Besides that, it is difficult to create action that 
contains several steps, for example copy + copy + copy + delete.

I agree that this is something we need
to support better. There is some scaffolding (thanks to Jeremiah) in place
to support including other makefiles that contain custom build steps but
I have not added any UI support for it. 

2) This leads me to another question. Is there any
way not only to  
build configuration from standard elements but also to specify 
class-implementor for any option category? Eventually it is very 
difficult to combine together convenience of UI and flexibility of 
implementation

One of the original design goals of
the managed build system was to make it possible for an implementer to
create a toolchain definition without writing any Java code. We could add
class implementer information to an option to support an advanced users.
I assume you want to be able to define the behaviour of the option when
it answers its contents and commands to the makefile generator?

3) It could be real disaster to support all possible
configuration. Is 
there a way to specify general options for all configurations and all 
targets and then just for some variants to modify common settings. I 
mean something like option "All" for Platforms and Configurations.
Otherwise would I like to change level of warnings for example, I have
to visit and update all configurations.

This is in the FDS, and I will try to
get it implemented for 2.0, but it is proving to be slightly more complicated
to pull off than you'd think because the UI is designed to represent an
actual configuration. Creating a temporary configuration that only shows
the union of the options for all defined configurations is time consuming....

4) I already wrote about that in this mailing list,
but didn't find any 
response. We should distinguish references to file system elements and
workspace elements. Keeping in mind projects sharing, every workspace 
element can and should be done relocatable. As long as workspace element
can live in any external folder, physically being located somewhere out
of work space,  builder should be able to resolve this location 
dynamically. I mean that: a) for workspace element it is a good idea not
to use absolute path to not depend on workspace location; b) 
Workspace-relative path of element should not depend on its physical 
location relative to workspace. It is also seems to be convenient to 
have in some cases two Browse buttons: one to pick up workspace element
and one to pick up  the file system element.

I think people have shied away from
giving a definitive answer here because this is a tough issue. There are
three clients of this information; the user, the scanner/parser, and the
tools that build the project. We need to support relative paths so that
projects and files can be relocated to team members on different machines,
but they have to be defined relative to *something*. If we are trying to
build a good UI, then the path should be relative to something the user
cares about and can wrap their heads around, like the workspace or / or
C:\. 
The internal clients like the indexer
and parser need to know exactly where file X is located on machine Y to
work. The relative paths have to be resolved by the build model and passed
to these client. The internal representation is up to us, really. I don't
see why we have to show the user this at all and I would certainly argue
against multiple browse buttons in the UI for esthetic and usability reasons.
The tools we call on the command line
also need to know where those files are, although they may accept paths
relative to where they are invoked, which may not be in the workspace subtree.
I suspect that the user will enter information in the UI that makes these
tools work, so by satisfying the user requirements first, we can (probably)
satisfy the tools as well.

5) Is there a way to inhibit some platforms I've got
with CDT? For 
instance, I don't use cygwin, but I don't understand how to remove it 
from the selection list in New Project wizard.

The short answer is no. If a variant
is defined, it will show up in the wizard. Once you have selected a target
for a project, you don't see them. What is the feature request here? Are
you saying that for a real commercial product, you have to be able to filter
out the targets you don't want users to create? That seems reasonable to
me, but the implementation might be to handle this through your own wizard
that filters non-QNX targets out of the list. If we need to add more information
to the target to help the wizard figure this out, we can. I am totally
open to suggestions that will make it easier to roll out products, though.

6) Any ideas how in managed builder to recompile selected
file? How to 
define file-specific options, for example, the level of optimization?

I don't see this as a technically difficult
problem, just a bookkeeping exercise. However it is a must-have item for
most people and I think we can probably bump the priority of it for the
2.0.1 timeframe. Given the lateness of the hour, to attempt this so close
to M9 is foolhardy.

7) I don't understand how to manage error parser stuff.
Is there a way 
to assign error parser to any tool chain?

This has been discussed before. At the
moment there is not.  It is needed, though.

8) I haven't found out an easy way to let builder know which variant I
want to build. Is there any way to do that without opening of Properties
dialog?

No. We need to add the available list
of variants to the build menu item or add a custom variant selector in
the menu bar of the C/C++ Projects view, or.... Any suggestions?  

Thanks,

Alex Chapiro, QSSL
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev