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"<a...@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
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
