Answers inline.. James Carlson wrote: > "C. Bergstr?m" writes: > >> James Carlson wrote: >> >>> The political aspect, if there is one, is the development process >>> around all of this, which includes the rules for gatelings: you must >>> test, you must do so on all affected platforms, and you must do so >>> thoroughly. The political aspect of adding a new compiler to the mix >>> is that you'd be forcing every ON contributor to compile three times >>> instead of the current two -- just to make sure that your "open64" >>> support doesn't itself suffer bit-rot in the gate. That's not >>> necessarily a bad thing, but it's a non-zero change, and would take >>> work. >>> >>> >>> >> Hi James.. >> >> At the very least I appreciate your very insightful reply.. >> >> Just because it compiles. .does it mean it boots? I *highly* doubt gcc >> gets anywhere near the same level of testing that suncc does.. >> > > Indeed, it doesn't get that level of testing at all. > > The only thing we're guarding with the current development process is > that it successfully compiles with gcc. It took quite a bit of work > by a small army of people to guarantee _that_ much, and it was done > specifically for the benefit of folks who feel that it's necessary for > all bits to be open source, and not just a subset. > > I agree that we could do much better here, if we had the resources to > test and deploy the gcc-built variant as well. > > What I've been pointing out is that the path you're suggesting for > "open64" doesn't even result in the same level of "it still compiles > after the next project integrates" goodness. It works once. > My work will make it easy to swap compilers for the whole stack.. shadow ensures it compiles, but I'm aiming to ensure it works and runs properly. My work won't magically make things portable, but will give people a reproducible way to pick up where someone may have left off or duplicate their efforts. So /technically/ dropping in gcc, SS12, SSX, icc, or open64 would be a matter of adjusting a profile for that toolchain. > <snip /> > > Lowering the barriers to testing sounds like a good thing, but it's > somewhat unclear to me how open source versus freely redistributable > binaries actually factor into the tool chain. > In this specific case and I'm following a *hard* line on the licensing agreement for what bits are fully redistributable. There is not a version of SS12 (the currently supported compiler) which is freely redistributable and also doesn't contain the evaluation clause in the agreement when you download. It is possible to pull a version of SSX from pkg.os.o directly and use that for commercial purposes. I have a script that requires only posix awk, ksh93 and wget. (useful for distros that don't use IPS) There's no login required and it's under the OpenSolaris binary license.
To the point.. source ensures that any point in the stack from compiler to userland any bug in theory could be resolved. (My initial work *is* using SSX from pkg.os.o and I'm quite happy with it, but long term I'm not sure how license zealots will feel about it.) > I *think* you're talking about a political position there. It's an > admirable one, and I agree with you that it'd be great if all source > were open, and that it's good to do things that move us (and others) > in that direction. > (Most Sun employees are great.. and I do appreciate the time/effort/knowledge that's continuously shared.. I'm sure if these things could be solved instantly.. there's a few people who would just do it..) > However, I don't see how solving that issue raises, lowers, or does > anything about the testing barriers, which have much more to do with: > > - The expense and complexity of maintaining farms of test machines, > particularly for specialized targets (say, a machine with 192 CPUs > and multiple 10Gbps Ethernets). > Instead of a centralized approach.. if it's trivially easy to setup/reproduce/test something people that have this hw and care may/will do it. The problem is you get a scientist who only cares about testing and not the pita of setting up pkgbuild/pkgtool.. nightly, opensolaris.sh or the 20 other things in the middle to sanely getting these binaries installed in a clean way. Need evidence.. I'll point you to a thread or two on the hpc-dev list.. > - The difficulty in setting up unusual test configurations. > > - The fragility and frankly low quality of some of the existing test > suites. > Can't comment on this, but for me always the best test application is the one the customer will actually be using. > - The fact that some of the tests aren't available outside of Sun in > any usable form, binary or source. > Distributed testing.. if someone finds a regression and needs help finding the exact cause.. Work with them.. It's not like FreeBSD or linux kernel has anything centralized that's being shared.. > - The requirement to have lots of third-party equipment for > interoperability testing. > > These are serious issues, and I hope that they'll improve with time, > but I'm a little unclear on how adding a new compiler to the mix or > shuffling around a library helps. Maybe it does, but I don't quite > see it. > > I mentioned a different compiler, but that's one of four changes of which is least influential to this. ./C
