RE: Headless build [was Re: [cdt-dev] RIP Wascana, Build System discussion]
We use MBS at TI heavily and it is the primary way for our customers to manage projects. We have developed headless project build, project import and project create in a similar way as is described below.
Project create is an interesting one as it allows some of our customers to have a different primary build system and auto generate necessary CDT projects for use within Eclipse.
We would be willing to contribute above functionality for CDT "Next" if there is interest.
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of James Blackburn
Sent: May 22, 2009 2:24 PM
To: CDT General developers list.
Subject: Re: Headless build [was Re: [cdt-dev] RIP Wascana, Build System discussion]
2009/5/22 Elena Laskavaia <elaskavaia@xxxxxxx>:
> Implementing headless builder from CDT is pretty straight forward. It is
> like 100 lines of code
Indeed, that's been my experience, though I haven't before now needed
to implement my own IApplication target instead using the one provided
by the platform as worked fine:
> to register eclipse "application" which would parse extra arguments such as
> project-list (or workspace) and maybe configuration to build.
> This of cause needs eclipse (headless) and java to run, but starup time is
> few seconds so it not that bad.
> If I have time I can look at contributing it to CDT.
That would be good :) Though post API freeze it would have to wait for 7, no?
I guess what I was trying to fish from people is what requirements
they've got that the existing workspace builder doesn't get right.
Project import's likely a big one so you don't need to have a
> James Blackburn wrote:
>> Hi All,
>> There seems to be a general consensus that headless build with the
>> managed builder isn't possible. I've been doing this successfully...
>> I guess my question is: why isn't this working for people? What
>> _exactly_ is it that doesn't work right?
>> I'm using headless managed build as described in the comments on:
>>> Can you just build the generated Makefiles?
>> Not ideal for a number of reasons:
>> - apparently the automatic makefile builder uses absolute paths in
>> the generated Makefiles.
>> - version controlling model generated files seems like a bad idea:
>> you have no idea whether the files agree with the contents of the
>> - you're tied you to the Makefile generator rather than internal
>> builder (which places a burden on maintenance and improving the
>> internal builder as chris has pointed out)
>> - and in some VCSs checked out files are read-only -- Try building
>> the project in a clearcase web view !
>> In my mind the managed build system should be simple & fast, as the
>> primary requirements, for the _average_ user to use. Like VS it should
>> just work and build projects without the user having to worry. I
>> think using Makefiles as the intermediate build runner is a bad idea.
>> The internal builder should provide a flexible fast build mechanism
>> that doesn't require regenerating the make files -- like users have
>> come to expect in the JDT.
>> Having fulfilled the simplicity criteria for managed build, users who
>> want headless build should be using the _same_ system for their
>> headless builds as they do for their day to day work.
>> Users of make, scons, whatever, run their scripts on their checkout,
>> and have their automated tests run the _same_ scripts in the
>> regression tests. There's no reason that CDT IDE users who build all
>> day long in the IDE shouldn't have their regression scripts fire up a
>> headless Eclipse to perform the build.
>> So what am I currently able to do?
>> We use a central shared install Eclipse which is run through a shell
>> wrapper script (this helps versioning and conserves disk space -- we
>> don't need an Eclipse install per user).
>> Using this script users can type:
>> ./eclipse <= to run the IDE
>> ./eclipse --build /path/to/workspace <= cleans and builds all the
>> projects in the workspace (headless)
>> ./eclsipse --build-gcno /path/to/workspace <= build with profiling
>> directed optimisations
>> So a regression script can:
>> - update project checkouts
>> - build
>> - run the regression suite
>> The build-gcno switch causes the managed builder to set fprofile-arcs
>> which allows the automated system to produce better optimised binaries
>> via: checkout -> build-with-instrumentation -> run ->
>> rebuild-without-instrumentation -> optimised product
>> The point of this is that it's straightforward to pass any switches
>> you wish to the compiler. All you need is for your runner to set some
>> system properties on the eclipse java instance, and provide a Command
>> Line Generator (proxying the default generator) to add / change
>> whatever you want at build time.
>> One of the things we don't currently do -- and something I've had
>> requests for -- is build "just a project" as project's need to belong
>> to a Workspace. I've seen IBM have some headless targets for
>> importing projects into the workspace, and this isn't hard to do. In
>> the next week or so I'm extending our product to do just that (it'll
>> create a temporary workspace in /tmp and import / build as the user
>> It would be neat to have more advanced functionality supported by CDT
>> itself, but for the case of headless regression builds I've not had
>> any trouble doing this...
>> Is there something I'm missing? If people want I can post a little
>> plugin to bugzilla which does the automatic project import and clean
>> build as an example of what can be done.
>> P.S. This is completely separate from the Standard Make Makefile
>> modification API that doug's proposed improving. With my other hat on,
>> that's needed too :).
>> In my mind any other build system integrations should fall in the
>> standard build camp. The automated internal builder should be simple
>> and efficient (at least then we're not trying to sprint before we can
>> walk :) ). Th APIs provided by the standard build system could allow
>> ISV additional flexibility to interface to and generate build scripts
>> for their-builder-of-choice.
>> cdt-dev mailing list
> cdt-dev mailing list
cdt-dev mailing list