All,
I stumbled across the minutes below from a recent PMC meeting. I've
highlighted a line of particular interest.
FWIW, I think that rules are made to be broken when they are
obviously counter-productive. If it makes sense for Eclipse to build
its Windows binaries using MSVS, then by all means let's figure out
a way to make that happen. Causing a whole pile of work for people
to workaround a rule just seems like a waste of effort. If there are
compelling reasons to port the build to use a cross-compiler, that's
fine. But if you're only doing it to resolve this constraint, then
let's talk about it.
February 18, 2015 - Dani, Alex, Martin
- Alex: Building Native Launchers
- Current
way of building is kinda unpredictable - even if getting
some agreement on versions to use, results are kinda
unpredictable
- Pushing
towards Hudson RHEL builders at least at the EF to get more
transparency and automation - attempt to mimic the
infrastructure at IBM
- Looking
at 3 primary architectures (at the EF) for Linux vs.
secondary architectures (non-public builders potentially)
- Dani:
Great initiative, but other (non-EF) builders must not be broken
- EF doesn't allow any commercial tools
(but currently, e.g. Windows launchers are built with
MSVS)
- Alex is
willing to spend time to get Linux builds running; but can't
help with other architectures
- Martin:
great approach - for Windows, using a cross-compiler on
Linux might be interesting (after Linux native works)
- Alex:
This is just phase one - getting rid of the binaries in git
repos might be phase 2 (since the checked-in binaries easily
cause inconsistencies between Java and Native side)
- Martin:
Checked-in binaries help consumers and contributors who just
want to make a Java change
- Dani:
Checked-in binaries are also used for comparing build
results for expected vs accidental changes
|
