RE: [cdt-dev] Managed Make and how you use it
good to see so many others interested in this.
1.2, I do understand and agree that the main dev focus is on 2.0. But also
there are those in my position where we'll need to use 1.2 for a while still and
we need the issues addressed now. I can see myself doing the
tracking patches and changes to 2.0, and porting back to 1.2 for my
producing 1.2 patches to problems and presenting back to cdt-patch and here for
inclusion in 2.0.
This is a tough question to answer, partly
because it's Friday but mainly because we are only just starting to get
feedback from people trying to use the managed build system for something more
complicated than building simple C/C++ projects. I think people have been
rolling their own build systems because there has not been any other way.
Realistically, the managed build
framework needs work. Unfortunately, the only way to see if it is sufficiently
flexible is for other people to try and add tools to it. For example, maybe
the makefile generator should be defined via an extension point and
implementers be allowed create their own if the default implementation is not
good enough. We just do not know until someone else tells us. To that end, I
am trying to be responsive to suggestions from anybody who has a change to
propose (preferably with a patch, documentation, and a rationale attached to
it). Personally, I think we would be better served if we put our collective
effort into improving the framework, but I understand that good intentions do
not always translate to shareholder value.
Maybe more to the point, I do not see the 1.2 managed
builder getting any further attention as we are focussed on 2.0 at the moment.
Anyway, I hope this kicks off the
discussion you are hoping for.
Rational Software - IBM Software Group
Sent by: cdt-dev-admin@xxxxxxxxxxx
02/27/2004 12:24 PM
|[cdt-dev] Managed Make
and how you use it|
I'm trying to use the Managed Make (1.2.0) for our cross-compiler
toolchain (toolchain includes source code cross-compilation and resource
definition compilations), but I'm running into problems right out of the gate.
Examples of such are:
- Spaces in the paths for dependencies
- ManagedBuildInfo schema doesn't contain listOptionValue for
- No variable support for paths like in JDT
with other input/output extensions (in my case xrd and trc respectively)
cannot be integrated because the makefiles think in terms of C and CPP source
files. (The makefile generates the variable's OBJS content by replacing
CPP_SRCs contents .cpp with .o, but in my case CPP_SRCS is set to a.xrd, so
the result in the clean statement is my source file a.xrd is
Some of these are addressed in CDT 2 and some in patches.
But my general concern that I'm trying to grasp is the state of the
Managed Make facility in terms of flexibility. Are most people finding
that it fulfills their needs (it seems to be very .c/.cpp to executable
centric)? Or do are a lot of people rolling their own managed make
(seemed that way at EclipseCon)? Any common technique you're using for
extending/reusing Managed Make (e.g. inheriting from most classes, or just
rewrite your own classes)?
Any gut feelings you guys have would be
helpful. Actually the most useful thing would be a best guess list of
weak areas in the Managed Make facility in CDT 1.2. So if anyone sees
areas where Managed Make is lacking or areas that you needed to touch, I'd
I don't want to roll my own and I'd like to
leverage/modify CDT 1.2.x as much as possible, but I'm getting the impression
that modifying may take a lot of