Re: [cbi-dev] Summary for conf call for having native parts builds moved

[Aleksandar Kurtakov <akurtako@xxxxxxxxxx>]

I admit being late with this one but other work took priority.

Tracking bz is https://bugs.eclipse.org/bugs/show_bug.cgi?id=476642 . Will continue filing stuff next week.

Alexander Kurtakov
Red Hat Eclipse team

----- Original Message -----
> From: "Aleksandar Kurtakov" <akurtako@xxxxxxxxxx>
> To: "Common-build Developers discussion" <cbi-dev@xxxxxxxxxxx>
> Sent: Thursday, 20 August, 2015 6:50:15 PM
> Subject: [cbi-dev] Summary for conf call for having native parts builds moved to eclipse.org infra
> 
> Eclipse.org infra is heading towards providing infra for rebuilding the
> native parts of Eclipse platform for Win, Mac, Linux x86_64 (x86?). There
> are more parts that contain native code but the two crucial parts are SWT
> and Equinox Launcher so work starting on them. For simplicity the first
> ws/os/arch combo to be worked on will gtk.linux.x86_64.
> Current native build scripts are monolithic in terms of one platform failing
> to builds leads to none recieving rebuilt native library. New approach will
> be that whatever platform succeeds in rebuild is committed and the rest will
> be let to fail during the aggregation or tests run. Natives not done
> @eclipse.org (rest of ws/os/arch combos produced currently) will be
> contributed by member companies and it will be their duty to sync up builds.
> N-builds and I-builds might have some different requirements for
> synchronization.
> A proposal for contributing a remote machine maintained at member company but
> being attached as Hudson slave for doing the build for additional platforms
> was done by Mikael not much interest in it now (Mikael, please ellaborate).
> Build will be done in Hudson with one job per platform, build with Maven -
> `mvn clean verify -Dnative=ws.os.arch` to open the door for simplifying the
> build script and hudson will commit to the git repo (noone objected). What
> about version bumps/tags/etc.? Don't remember being discussed.
> 
> Initial work plan is:
> 1. Duplicate platform repos in cbi for swt.binaries, equinox.binaries and
> releng.aggregator (to make submodules point to cbi swt.binaries,
> equinox.binaries repos).
> 2. Get slaves for build machines - RHEL being a blocker for the initial work,
> Mac/Win to open paralel fronts
> 3. Have builds running on this slaves - Most things available now, only big
> missing thing is Xulrunner AFAIK.
> 4. Get hudson committing to the cbi git repos on successful builds
> 5. Run aggregation job - it would produce all the tarballs/zips but only the
> one targetted will be expected.
> 6. Find some comparator tool and run it against zip produced by this new
> build and the old way produced one to find potential differences.
> 
> Additional points from the talk:
> * It would be nice to decouple platforms as maven profiles so only one of
> given subset can be built (David) - It would not be build scripts work only
> but it would require work on PDE side to allow it as fragments are included
> in features and they have to be resolved even if the platform is not going
> to be build in this run. Can be tackled as separate project if people
> interested in it.
> * PDE is using hardcoded arch list - would be nice to have it dynamic in some
> way based on contributed archs
> 
> Let's have initial read and corrections and I'll start filing bz to get
> tracking for all the tasks.
> 
> Please correct, extend, add for whatever I missed or misunderstood,
> Alexander Kurtakov
> Red Hat Eclipse team
> 
> _______________________________________________
> cbi-dev mailing list
> cbi-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/cbi-dev
>