Gregory Shimansky wrote:
On Saturday 16 December 2006 01:20 Geir Magnusson Jr. wrote:
My personal view is that we should statically link this crap into the
package so that there's no prereqs - just get harmony, run harmony, and
be in harmony.
I think we should get the understanding about what we are going to provide in
the end. The source or the binaries. Which way it would be easier (or
possible) to certify the package as Java?
There's no way to certify source. Only binaries are certified, they are
certified for specific platforms and configurations.
So anything that we call "Java" is going to be a binary.
I would definitely prefer to provide source and leave the integration to the
distributions. Same model is assumed by KDE or mplayer projects. They just
don't create any binaries, and all the bugs which are possible are to be
considered by the downstream distributions first, patches and fixes sent
upstream.
Anyone can do that too. We will absolutely distribute source. But
those source distros aren't "Java(tm)" and can't be considered
compatible w/o testing.
IMO, the odds of the distros securing TCKs is pretty small given current
political, legal and business conditions.
But I'm in the minority here...
Static linking doesn't work in many ways, on x86_64 for example. I don't
really care dynamic or static, but the reality is that static linking often
is just impossible.
I'm not suggesting it's one way or nothing - but the more we can do to
make it easy, the better.
We are many months away from "Java(tm)", so there's nothing that's
imperative to solve. But as noted, we can add to a "prereqs" list for
the snapshot, and start working out things like compiler we used for
disto, etc.
geir
Certainly for now, we need to notify people of the reqs..
geir
