Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Managed Make and how you use it

Hi Brad,
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.

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

"Brad Jarvinen" <Brad.Jarvinen@xxxxxxxxxxxxxx>
Sent by: cdt-dev-admin@xxxxxxxxxxx

02/27/2004 12:24 PM

Please respond to

"Cdt-Dev (E-mail)" <cdt-dev@xxxxxxxxxxx>
[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 don't work
- ManagedBuildInfo schema doesn't contain listOptionValue for optionReferences
- No variable support for paths like in JDT
- Tools 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 deleted.)

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 appreciate knowing.

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 effort.

cdt-dev mailing list

Back to the top