|Headless build [was Re: [cdt-dev] RIP Wascana, Build System discussion]|
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: https://bugs.eclipse.org/bugs/show_bug.cgi?id=186847 > 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 .cproject - 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 requests). 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. Cheers, James 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.
Back to the top