Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: Headless build [was Re: [cdt-dev] RIP Wascana, Build System discussion]

On 22 May 2009, at 19:32, Sergey Prigogin <eclipse.sprigogin@xxxxxxxxx> wrote:

On Fri, May 22, 2009 at 11:23 AM, James Blackburn <jamesblackburn@xxxxxxxxx> wrote:
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
preconfigured workspace.

Lack of support for multiple build targets within a single project makes it a non-starter for many existing projects. Consider, for example, a development practice when each class requires a unit test and each unit test is a separate build target.

Right, ive run up against this too. But this is a criticism of managed build in general rather than headless build, isn't it?

It'd be good to have multiple targets in the same build config, though I suspect this is a non trivial change to the workflows... Along a similar vein, setting build properties on multiple source files simultaneously is all annoying. 




> 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
>> .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.
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
cdt-dev mailing list

cdt-dev mailing list

Back to the top