RE: Headless build [was Re: [cdt-dev] RIP Wascana, Build System discussi

["Swiezawski, Martin" <mswiezawski@xxxxxx>]

> That does sound interesting. What sort of workflows does that allow?

In most cases Eclipse based tool is not the primary development tool or there is a different build system that is used for building/managing source due to legacy/infrastructure reasons. Project create could then be used to generate necessary Eclipse/CDT project files every night as part of a central build system. Eclipse/Project files are used every once in a while to facilitate quick edit/compile/debug cycle on developers machine. 

> How can you create and configure a full project from the command line?

...lots of options ;)


Martin

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of James Blackburn
Sent: May 29, 2009 3:36 PM
To: CDT General developers list.
Subject: Re: Headless build [was Re: [cdt-dev] RIP Wascana, Build System discussion]

For anyone not CCd on the bugs, I've put a patch up on the headless
build bug -- https://bugs.eclipse.org/186847

It can be used to:
  - import projects
  - build and
  - clean build individual projects or the full workspace.
It builds all CDT configurations in the specified projects / workspace.

2009/5/25 Swiezawski, Martin <mswiezawski@xxxxxx>:
> 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.

That does sound interesting. What sort of workflows does that allow?
How can you create and configure a full project from the command line?

Cheers,
James

>
> We would be willing to contribute above functionality for CDT "Next" if there is interest.
>
> Martin
>
>
> -----Original Message-----
> 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:
> http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.jdt.doc.isv/guide/jdt_apt_building_with_apt.htm
>
>> 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.
>
> James
>
>>
>> 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
>
> _______________________________________________
> 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