Darren J Moffat wrote:
> John Plocher wrote:
>> For things like cat, ls, ..., there is no real reason to
>> continually recompile and redeliver them on a nightly or
>> even bi-weekly basis - they don't change that often. What
>> would happen if they were built and pushed into a repo only
>> when they changed?
This was the argument made for the X.Org modularization - there's not a
month that goes by without some new graphics card coming out, and why
should xhost (which hasn't really changed since IPv6 support was added
5 years ago) be rev'ed just because the ATI or nVidia driver was?
On the other hand, if you don't recompile regularly, how do you know
that it's still the same next time you do need to change it? Our sources
are dependent on a twisty maze of system headers, libraries, compilers,
Makefile flags, etc. and aren't truly self contained.
Fortunately, IPS uses elfcmp-like technology to not push a new ls binary
if the bits are all the same, just with a newer compiler timestamp in.
> The major down side of that is that since the source almost never
> changes they wouldn't get the benefit of all the generic changes. For
> example ON related linker changes for direct binding, non executable
> stack, and in the past largefile support. On the other hand tools like
> ls actually did get quite a big set of changes recently and this might
> not have been as easy to do if they were in a consolidation other than ON.
>
> If they live in a different source code repository (consolidation) then
> when things like the direct binding support, or other "general goodness"
> projects, (that apply to very large chunks of code) wouldn't be so easy
> to get as large a benefit.
On the bright side, if there was less in ON, and people had to deal
with other gates on a regular basis, then there would be less people
who think they can change an ON master makefile and then declare
"Solaris is built with non-exec stacks" or "Solaris is built with CTF
data", when they really mean "The 10-20% of Solaris that is ON". (Not
trying to pick on those particular projects, they were just the first
to come to mind, speaking as the person who watches ON putbacks for
things like that to see which we should apply to the X gate as well,
and knowing that no one does the same for many other consolidations.)
But the cost of new consolidations in our current models is not cheap -
new build machines, gatekeepers, a C-Team, etc. Perhaps if those were
shared across consolidations, like we do with a single Desktop C-Team
covering JDS, CDE & X Consolidations, it wouldn't be so bad, but it's
still non-trivial.
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
