I'd like to remove the -r part from the uname call that creates the build directory names. That means that one would get build directories like this
build/linux-x86_64
instead of
build/linux-2.6.10-5-amd64-k8-x86_64
The reason is that I find it a bit annoying to have to discard all my pike build dirs every time I install a new kernel.
It also doesn't seem relevant to depend on the kernel version since it afaik doesn't affect the build environment. It'd be more apt to depend on the libc version (or actually the version of every lib that pike builds against).
Thoughts?
I'd love to see the same for shipped binary package names; it's rather misleading at present. (In so far as binary packages are useful at all at the moment, which might not be the case if they all fail to install on behalf of the refdoc misfeature noted recently.)
That's a Linux-specific problem; on other OS'es uname -r returns the main OS release number, and not the patch level (which is returned by -v). eg:
OS -s -r -v
AIX 5L/ia64 5.1 AIX 1 5 Linux 2.6.10/x86_64 Linux 2.6.10-5-amd64-k8 "#1 Tue Apr 5 12:10:43 UTC 2005" MaxOS X Darwin 7.9.0 "Darwin Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC" Solaris 8 SunOS 5.8 Generic_108528-06 Solaris 10 (unpatched) SunOS 5.10 Generic
Judging from the number of periods, I'd say OS X has the same behavior as Linux.
And what's with the "unpatched" on Solaris 10? Would a patch change things?
Even if we added some sed'ing to shorten the Linux (and MacOS X) version numbers I'd say they aren't relevant since the same binary would likely run well with both a 2.4 and 2.6 kernel, for instance.
What matters is mainly the libc version. Is that different between the Solaris versions? And if not, does it really matter if it's built in Solaris 8 or 10?
It would not be good for my installation at home. I compile from the same source directory on several different linux boxes.
So as it happens you use different kernel versions/builds on all of them then. That's a bit ad hoc. The right way to cope with that is instead to set $OS or introduce a new variable that is included in the $OS string.
It would screw up my Linux builds at home a bit since I build on several diffrent machines from the same NFS-dir. Not a big deal though. I would just have to remember to remove the build dir a bit more often. I habitually remove the build dir every other week anyway.
pike-devel@lists.lysator.liu.se