>
> 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:
>>
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.
>> _______________________________________________
>> cdt-dev mailing list
>>
cdt-dev@xxxxxxxxxxx
>>
https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
> _______________________________________________
> cdt-dev mailing list
>
cdt-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
