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]

Yep, a lot of these variables only make sense with a UI context.  In
3.5 you'll be able to use workspce_loc, but the others are still out
of bounds.

You should be using CDT variables like ${ProjDirPath} instead.

See: http://publib.boulder.ibm.com/infocenter/rsahelp/v7r0m0/index.jsp?topic=/org.eclipse.cdt.doc.user/reference/cdt_u_mprop_macros.htm
for a list of variables supported -- sadly last I checked this help
page is no longer part of CDT.

I've got some patches which make CDT and managed build work with
workspace paths.  The Managed build UI creates workspace relative
paths and translates them at build time.  This allows managed build to
work nicely with e4 flexible resources.  This will hopefully go in
early in CDT 7 if no one objects (I became committer too late in 6 to
do this...).

Cheers,

James

2009/5/25 Doug Schaefer <cdtdoug@xxxxxxxxx>:
> That UI-Error is exactly the problem with CDT headless builds. The variables
> framework used for build variables like resource_loc, is trying to invoke
> something in the UI layer.
>
> Doug.
>
> On Mon, May 25, 2009 at 4:31 AM, Kaestel-Baumgartner Harald (DCC/EDF2)
> <Harald.Kaestel-Baumgartner@xxxxxxxxxxxxxxx> wrote:
>>
>> > From: James Blackburn <jamesblackburn@xxxxxxxxx>
>> > > 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.jd
>> t.doc.isv/guide/jdt_apt_building_with_apt.htm
>> >
>>
>> For us the headless build (for managed projects) works without the
>> jdt_apt_building (avoids jdt dependencies in cdt).
>> org.eclipse.ant.core.antRunner and a simple build-script is enough. The
>> command looks like this:
>> "
>> ...\eclipse.exe -data <path to Workspace> -console -noSplash -application
>>  org.eclipse.ant.core.antRunner -buildfile build.xml -logfile build.log
>> -vmargs -Dorg.eclipse.cdt.core.console=org.eclipse.cdt.core.systemConsole
>> "
>>
>> There is a UI-Error in the .log-File that could be solved (cdt
>> 5.0.2.200902130801):
>> "
>> !ENTRY org.eclipse.osgi 4 0 2009-05-25 09:20:09.119
>> !MESSAGE An error occurred while automatically activating bundle
>> org.eclipse.debug.ui (75).
>> !STACK 0
>> org.osgi.framework.BundleException: Exception in
>> org.eclipse.debug.internal.ui.DebugUIPlugin.start() of bundle
>> org.eclipse.debug.ui.
>>        at
>> org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1028)
>> ...
>> Root exception:
>> java.lang.ExceptionInInitializerError
>>        at
>> org.eclipse.debug.internal.ui.DebugUIPreferenceInitializer.setDefault(DebugUIPreferenceInitializer.java:174)
>> ...
>> "
>>
>> Just my 2 cent ;)
>>
>> --Harald
>> _______________________________________________
>> 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
>
>


Back to the top