Date: Thu, 17 Mar 2011 18:49:30 +0100 From: Matthias Andree <mandree@FreeBSD.org> To: freebsd-ports@FreeBSD.org Subject: Re: Compiling ports in a post-9.0-RELEASE world Message-ID: <4D8249AA.6010406@FreeBSD.org> In-Reply-To: <94BB0206-E628-4365-95B8-4BC303288B93@freebsd.org> References: <4D7BED01.6000506@FreeBSD.org> <696141300213240@web70.yandex.ru> <20110316091948.GZ46044@droso.net> <20110316093938.GB12965@mech-cluster241.men.bris.ac.uk> <5868CD2A-5FE3-400F-B081-2123CD33BB48@FreeBSD.org> <9561300272310@web147.yandex.ru> <94BB0206-E628-4365-95B8-4BC303288B93@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 16.03.2011 12:02, schrieb Ade Lovett: > > On Mar 16, 2011, at 05:45 , Konstantin Tokarev wrote: >> 16.03.2011, 13:33, "Ade Lovett"<ade@FreeBSD.org>: >>> On Mar 16, 2011, at 04:39 , Anton Shterenlikht wrote: >>> >>>> What will happen to ports in non-clang arches (sparc64, ia64) after 9.0R? >>> >>> With any luck, they will die a silent death and be pointed in the direction of NetBSD that likes to look after irrelevant architectures. i386/amd64 for primary use, arm/mips for embedded. Anything else is just ridiculous. >> >> What about Power Architecrure (formerly PowerPC)? >> It's widely used both for embedded and enterprise (pSeries, Blue Gene, etc.) > > Surprisingly enough, there is an _enormous_ difference between making FreeBSD/src run on a particular platform (which is pretty much self-contained), and then making FreeBSD (src+22,000 ports) run on a particular platform (which isn't). > > Let's take the embedded example at random (well, not so much, since we both brought it up). Forcibly define WITHOUT_X11 on those platforms -- that'll nuke a whole bunch of stuff. That's the low hanging fruit. In fact, it may well be easier to define ONLY_FOR_ARCHES?= i386 amd64 in bsd.port.mk and then _override_ it for those few ports, and dependencies, that actually make sense on an embedded system. > > With 9.0-RELEASE, as far as ports/packages go, we'll be back to trying to support 4 major releases (7.4, 8.2, 9.0)-STABLE, 9.1-CURRENT (or will it be 10.0), two fundamentally different compilers (between 7.x/8.x and 9.0), eleventy-billion ports, with perhaps 2 people in the entire universe wanting to run doxygen on a mips box. > > Enough is enough. To make a very clear point: We wouldn't be having this discussion if authors would write proper and portable code in general. Not make silent assumptions about data width. Use proper POSIX headers rather than guess endianness or type width from arch-dependent preprocessor macros. Forget about pre-SUSv3 systems, or at least pre-SUSV2. Don't second guess from high-level system feature, but query the actual low level feature, or hardcode type widths if we're talking about binary data layout (file systems, file formats, or wire protocols, for instance). I don't mean to offend anyone or this to be taken reproachful, but it's just an observation: I've seen so much code make implicit assumptions such as sizeof(long) == 4, endianness being "little", OS being Linux, or if it's not i386 or alpha then foo and all that when in fact all the support such as inttypes.h or sys/endian.h for the few bytes that needed it had been in place when the code was newly written. I'm not asking about the reasons, but as an example: don't look at __i386__ if you need to know type widths and endianness. Getting this stuff shaken out and done right usually means not supporting one more platform per iteration but usually the whole lot. And it often also removes other system dependencies. Yes the releases * arches * compilers diversity is worrisome with expectations of lots of work, but the way to handle it is getting the code right. I expect that upstreams will be more attentive, too, as more core code might want to be ported to Android, for instance. And usually portable code is also better code in the sense that it is more robust and has fewer branches (or the branches are encapsulated in the magic under /usr/include). Pointing people to NetBSD and/or pkgsrc isn't helping anyone. If some arcane Java port fails on an architecture that's typically used for low-power, battery-powered, embedded stuff, so be it. But quite a lot of the console/infrastructure stuff can be fixed with little effort, and I'm not supporting artificial limitations. -- Matthias Andree ports committer
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D8249AA.6010406>