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 themhat about us. 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.
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.
What about using git branches to sync up builds? Today, all binaries are committed in a single commit and then tagged, and that make the sync quite obvious. What about using a git branch where all the platform binaries will be committed? The branch will match a commit in the source git repo and will then be the unit of synchronization. Picture is worth a thousand words so:
<PastedGraphic-1.tiff>
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).
The idea behind this proposal is to avoid having builds being contributed to the binary repo "out of nowhere". The way things will be done: an architecture will be build on a dedicated slave. The Eclipse Foundation commitment is about the three main platforms (linux, windows and macosx) in their respective 32/64 bits variants. Other archs will be provided by third parties. Instead of just committing the binaries in the binary repo, the idea is to connect the machines to the master hudson. It will let anyone with access to the Hudson master see the third parties build logs for transparency and it will also let the Hudson master triggers other archs builds when sync is needed. The third party slaves don't even need to have commit rights to the binary repo, this can be done by Hudson master. The main issue is that third parties must make their machine run a sshd visible to the internet. Again, a picture is worth... :
<PastedGraphic-2.tiff>
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.
Sounds like a plan. I will duplicate git repo mentioned above in cbi today.
Thanks.
