Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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