diff options
| author |   Mark Loeser <halcy0n@gentoo.org> | 2006-05-01 17:42:24 +0000 |
|---|---|---|
| committer | Mark Loeser <halcy0n@gentoo.org> | 2006-05-01 17:42:24 +0000 |
| commit | 202c2e69b4ea2c575f40dbd0137244bdb2c5c3f8 (patch) | |
| tree | c5032d62dfb9d3c356884604b4067b06777076c2 | |
| parent | Add subsubsection. (diff) | |
| download | devmanual-202c2e69b4ea2c575f40dbd0137244bdb2c5c3f8.tar.gz devmanual-202c2e69b4ea2c575f40dbd0137244bdb2c5c3f8.tar.bz2 devmanual-202c2e69b4ea2c575f40dbd0137244bdb2c5c3f8.zip | |
More goodies converted, hosted projects, and half of the archs
git-svn-id: svn+ssh://svn.gentoo.org/var/svnroot/devmanual/trunk@35 176d3534-300d-0410-8db8-84e73ed771c3
| -rw-r--r-- | archs/alpha/text.xml | 137 | ||||
| -rw-r--r-- | archs/amd64/text.xml | 715 | ||||
| -rw-r--r-- | archs/text.xml | 36 | ||||
| -rw-r--r-- | hosted-projects/text.xml | 166 | ||||
| -rw-r--r-- | text.xml | 2 |
5 files changed, 1056 insertions, 0 deletions
diff --git a/archs/alpha/text.xml b/archs/alpha/text.xml new file mode 100644 index 0000000..e156352 --- /dev/null +++ b/archs/alpha/text.xml @@ -0,0 +1,137 @@ +<?xml version="1.0"?> +<guide self="archs/alpha/"> +<chapter> +<title>Arch Specific Notes -- ALPHA</title> +<body> + +<p> +The ALPHA port uses the <c>alpha</c> keyword. It focuses upon HP (formerly Compaq +(formerly DEC)) hardware. This covers from <c>ev4</c> (known as 21064) through +<c>ev7z</c> (known as 21364a). +</p> + +<section> +<title>ALPHA Kernel and Userland ABIs</title> +<body> + +<p> +All ALPHA systems use a pure 64 bit kernel and a pure 64 bit userland. +</p> + +<p> +All ALPHA systems support both little and big endian <d/> however, Linux only uses +little endian. +</p> + +</body> +</section> + +<section> +<title>Additional ALPHA Keywording Requirements</title> +<body> + +<p> +It is generally expected that anyone who does keywording for ALPHA should be on +the <c>alpha@</c> alias. However the ALPHA Team is happy if maintainers keyword +their packages when they have access to ALPHA hardware, although the Team would +like to know about it. +</p> + +</body> +</section> + +<section> +<title>ALPHA Instruction Set and Performance Notes</title> +<body> + +<p> +There are six basic ALPHA instructions set standards: +</p> + +<ul> + <li> + <c>ev4</c> or <c>ev45</c>. The <c>ev4</c> was the first ALPHA processor of the Alpha + family. It featured one integer pipeline and one floating-point pipeline. + The <c>ev45</c> is a modified <c>ev4</c> with double both Data and Instruction cache + (D-Cache and I-Cache respectively); it also featured a division optimization. + </li> + <li> + <c>ev5</c> is an evolution of the <c>ev45</c>. The number of pipelines was doubled + and the floating-point pipelines run in 9 stages rather than in 10. The + <c>ev5</c> supports 3 cache levels. + </li> + <li> + <c>ev56</c> added the BWX extension to load/store data in 8 or 16 bit quanta. + </li> + <li> + <c>pca56</c> added a new set, MVI (Motion Video Instructions), aimed to + accelerate video and audio calculations. + </li> + <li> + <c>ev6</c> supports all extensions supported by the <c>pca56</c> and a new set, FIX, + meant to move data between integer and floating-point registers and for square + root. + </li> + <li> + <c>ev67</c> is an evolution of the <c>ev6</c>, in addition it supports a new set. + CIX adds instructions for counting and finding bits. + </li> +</ul> + +<p> +When no <c>-mcpu</c> option is passed to <c>gcc</c> it defaults to the processor on +which the compiler was built. +</p> + +<p> +The <c>-mieee</c> flag <b>should</b> always be used unless you have a deep knowledge +of the ALPHA architecture, so the comments on +<uri link="::general-concepts/user-environment#Not Filtering Variables"/> are +really important on ALPHA. +</p> + +</body> +</section> + +<section> +<title>Notes on ALPHA and PIC</title> +<body> + +<p> +General <uri link="::general-concepts/pic/"/> policy also applies to ALPHA. In fact, +ALPHA systems complain loudly if you try to link PIC and non-PIC code. Usually +this results in errors during the compilation aborting emerge. +</p> + +</body> +</section> + +<section> +<title>Contacting the ALPHA Team</title> +<body> + +<p> +The ALPHA team can be contacted: +</p> + +<ul> + <li> + Via Bugzilla bugs assigned to <c>alpha@</c> + </li> + <li> + Via email to the <c>alpha@</c> email alias + </li> + <li> + Via email to the <c>gentoo-alpha</c> mailing list + </li> + <li> + Via the <c>#gentoo-alpha</c> IRC channel on Freenode + </li> +</ul> + +</body> +</section> + +</body> +</chapter> +</guide> diff --git a/archs/amd64/text.xml b/archs/amd64/text.xml new file mode 100644 index 0000000..581fda4 --- /dev/null +++ b/archs/amd64/text.xml @@ -0,0 +1,715 @@ +<?xml version="1.0"?> +<guide self="archs/amd64/"> +<chapter> +<title>Arch Specific Notes -- AMD64/EM64T</title> +<body> + +<section> +<title>Position Independent Code Issues</title> +<body> + +<p> +Gentoo Policy demands all shared objects to be compiled with <c>-fPIC</c> +in <c>CFLAGS</c>. Since this is only a rule, you *can* break it on some arches. +You might never notice it. On AMD64, this is a necessity, if shared objects aren't +built with support for position independent code, the build process bails out +with an error message like this: +</p> + +<pre> +foo.o: relocation R_X86_64_32 can not be used when making a shared +object; recompile with -fPIC +</pre> + +<subsection> +<title>How to fix -fPIC issues</title> +<body> + +<p> +There are several ways to enforce <c>-fPIC</c> on shared objects, each with its +pros and cons. +</p> + +<subsubsection> +<title><c>sed</c>'ing the Makefile</title> +<body> + +<p> +Sometimes, a simple <c>sed</c> command is enough to fix it, however, the statements +normally aren't very readable and may fail when upstream changes the file. +Please verify that you only change the <c>CFLAGS</c> for *shared* objects, not for +the whole package. +</p> + +</body> +</subsubsection> + +<subsubsection> +<title>Patching <c>Makefile.in</c>/<c>configure</c></title> +<body> + +<p> +This is more readable, and easier to send upstream. +</p> + +</body> +</subsubsection> + +</body> +</subsection> + +<subsection> +<title>How <b>not</b> to fix -fPIC issues</title> +<body> + +<p> +Do <b>not</b> patch the <c>Makefile</c> itself, since it is usually generated by the +<c>configure</c> script and may vary heavily, so the patch could fail. Also, this +doesn't help upstream at all. +</p> + +<p> +Another bad idea is to (ab)use <c>append-flags</c> function from +<c>flag-o-matic.eclass</c>. Applying <c>-fPIC</c> on all objects will slow down the +binaries in a drastic way. +</p> + +</body> +</subsection> + +</body> +</section> + +<section> +<title>Assembler Optimisation</title> +<body> + +<p> +Modern x86 processors support special instruction sets like <c>mmx</c>, <c>sse</c>, +<c>SSE2</c> and <c>3DNow!</c>. AMD64 also provides support for them, but in most +cases, x86 assembler code is incompatible with AMD64 assembler. There are lots +of packages that provide support through USE flags for these instruction sets. +Originally, the USE flags were introduced to keep support for older processors +such as the Pentium I that can't handle such code. Currently, all AMD64s support the +same combination of extended instruction sets, so there is no reason to make +use of the mentioned USE flags. That's why these USE flags are hard-masked in +all AMD64-profiles. This doesn't mean we don't support the extensions +themselves, instead, we hard-enable them. +</p> + +<p> +The following USE flags are masked on AMD64: +</p> + +<ul> + <li> + mmx + </li> + <li> + mmx2 + </li> + <li> + sse + </li> + <li> + sse2 + </li> + <li> + 3dnow + </li> + <li> + 3dnowext + </li> +</ul> + +</body> +</section> + +<section> +<title>Multilib on AMD64</title> +<body> + +<p> +The current AMD64 processors are able to natively run 32bit code on a 64bit +kernel. Therefore, you can run programs compiled for x86 in an amd64 environment. +However, 32bit applications need to be linked against 32bit libraries. Mixing +them won't work. For this reason the libraries are sorted, 32bit libraries normally +go to <c>/lib32</c> respectively <c>/usr/lib32</c>, the 64bit ones normally to <c>/lib64</c> or +<c>/usr/lib64</c>. In a perfect world, you wouldn't have to read on. Unfortunately, +that's not the case, and so it's a bit more complicated. +</p> + +<subsection> +<title>Multilib-Toolchain</title> +<body> + +<subsubsection> +<title>GCC</title> +<body> + +<p> +To generate 32bit code, we need a multilib-capable GCC. On other architectures, +this functionality is enabled with the USE flag <c>multilib</c>. This is also true +for amd64 with the <e>pre</e>-2005.0 profiles. From 2005.0 on, you have to choose +whether you want multilib support or not by selecting the profile. Choose +<c>2005.0/no-multilib</c> if you don't want it, all other profiles have the +<c>multilib</c> USE flag masked, you're forced to it. With these profiles, GCC will +produce x86-code whenever you add <c>-m32</c> to its command line. Adding <c>-m64</c> +or omitting any bit-width option will default to producing 64bit code. +</p> + +</body> +</subsubsection> + +<subsubsection> +<title>glibc</title> +<body> + +<p> +If you've chosen a multilib profile, glibc will be built twice, once 64bit and +once 32bit. This is because nearly every application links against glibc. +To understand how this is done in the ebuild, read +<uri link="::arch/amd64/#The ABI Variable"/>. +</p> + +</body> +</subsubsection> + +</body> +</subsection> + +<subsection> +<title>The <c>emul-linux-x86-*</c> packages</title> +<body> + +<p> +As you read above, 32bit applications must be linked against 32bit libraries. +For that, we've put together the most used libraries and stuck them into the +so-called <c>emul-linux-x86</c> packages, which are located in the +<c>app-emulation</c> category. +</p> + +<dl> + <dt> + emul-linux-x86-baselibs + </dt> + <dd> + <p> + Contains very basic libraries like zlib, pam, ncurses. + </p> + </dd> + <dt> + emul-linux-x86-compat + </dt> + <dd> + <p> + Contains very old libraries for compatibility with binary-only programs. + </p> + </dd> + <dt> + emul-linux-x86-glibc + </dt> + <dd> + <p> + Only used for compatibility reasons. This package is blocked by all + 2005.0 profiles. + </p> + </dd> + <dt> + emul-linux-x86-gtklibs + </dt> + <dd> + <p> + The name says it -- GTK and its engines belong herein. + </p> + </dd> + <dt> + emul-linux-x86-nvidia + </dt> + <dd> + <p> + Obsolete, <c>media-video/nvidia-glx</c> includes the 32bit library. + </p> + </dd> + <dt> + emul-linux-x86-qtlibs + </dt> + <dd> + <p> + QT goes here. + </p> + </dd> + <dt> + emul-linux-x86-sdl + </dt> + <dd> + <p> + libsdl and friends are here. + </p> + </dd> + <dt> + emul-linux-soundlibs + </dt> + <dd> + <p> + alsa, libogg, just everything that is needed to get sound is located here. + </p> + </dd> + <dt> + emul-linux-x86-xlibs + </dt> + <dd> + <p> + Contains the basic X libraries. + </p> + </dd> +</dl> + +<p> +These packages only provide pre-compiled libraries. Currently, the +archives are assembled manually, which is the main reason to keep the packages +as tidy as possible. Do not include libraries that aren't commonly used. +</p> + +<note> + The emul-packages might conflict with their native images, but only in + uncritical locations like <c>/usr/share</c> which are arch-independent anyway. +</note> + +</body> +</subsection> + +<subsection> +<title><c>Libdir</c> Links</title> +<body> + +<p> +Currently, we provide several profiles, each with its own combination of <c>libdir</c> +configurations. +</p> + +<table> + <tr> + <th> + Profile + </th> + <th> + lib32 + </th> + <th> + lib + </th> + <th> + lib64 + </th> + </tr> + <tr> + <ti> + 2004.3 + </ti> + <ti> + *l->emul* + </ti> + <ti> + d64 + </ti> + <ti> + *l->lib* + </ti> + </tr> + <tr> + <ti> + 2004.3/lib64 + </ti> + <ti> + *l->emul* + </ti> + <ti> + *l->64* + </ti> + <ti> + d64 + </ti> + </tr> + <tr> + <ti> + 2005.0 + </ti> + <ti> + d32 + </ti> + <ti> + *l->64* + </ti> + <ti> + d64 + </ti> + </tr> + <tr> + <ti> + 2005.0/no-multilib + </ti> + <ti> + d32 + </ti> + <ti> + *l->64* + </ti> + <ti> + d64 + </ti> + </tr> + <tr> + <ti> + 2005.0/no-symlink + </ti> + <ti> + d32 + </ti> + <ti> + d + </ti> + <ti> + d64 + </ti> + </tr> + <tr> + <ti> + 2005.0/no-symlink/no-lib32 + </ti> + <ti> + inexistant + </ti> + <ti> + d32 + </ti> + <ti> + d64 + </ti> + </tr> +</table> + +<dl> + <dt> + d + </dt> + <dd> + <p> + Directory containing mixed-bit objects + </p> + </dd> + <dt> + dXX + </dt> + <dd> + <p> + Directory containing XXbit objects + </p> + </dd> + <dt> + l->foo + </dt> + <dd> + <p> + Link to foo + </p> + </dd> +</dl> + +<p> +To always get the right path, you should use the function <c>$(get_libdir)</c> from +<c>multilib.eclass</c>. It will always return the correct directory, on all arches. +And of course it also takes care of the <c>ABI</c> variable. +</p> + +</body> +</subsection> + +<subsection> +<title>The <c>multilib-strict</c> Feature</title> +<body> + +<p> +Many Makefiles assume that their libraries should go to <c>/usr/lib</c>, or +<c>$(prefix)/lib</c>. This assumption can cause a serious mess if <c>/usr/lib</c> +isn't a symlink to <c>/usr/lib64</c>. To find the bad packages, we have a portage feature +called <b>multilib-strict</b>. It will prevent emerge from putting 64bit libraries +into anything other than <c>(/usr)/lib64</c>. +</p> + +<p> +<c>multilib-strict</c> currently doesn't check perl5, gcc, gcc-lib and eclipse-3, +this behaviour is controlled by the <c>MULTILIB_STRICT_EXEMPT</c> variable in +<c>make.profile</c>. +</p> + +<subsubsection> +<title>How to fix ebuilds properly</title> +<body> + +<p> +In most cases, it's sufficient to use the <c>$(get_libdir)</c> function from +<c>multilib.eclass</c>: +</p> + +<codesample lang="ebuild"> +inherit multilib + +src_compile() { + econf \ + --libdir=/usr/$(get_libdir) + + emake || die +} + +src_install() { + make DESTDIR=${D} install || die +} +</codesample> + +<p> +Some packages provide really bad Makefiles which hard-code <c>/usr/lib</c>. Those +should be <c>sed</c> -ed or patched. Don't forget to let upstream know about your +modifications! +</p> + +</body> +</subsubsection> + +</body> +</subsection> + +<subsection> +<title>Headers and Multilib</title> +<body> + +<p> +Most C/C++ programs need standard header files like <c>types.h</c>. Some of them +depend on architecture specific facts, e.g. <c>types.h</c> on the length +of machine words. To ensure that we can compile both 32bit and 64bit +applications and libraries, we treat <c>/usr/include/asm</c> a bit special. +</p> + +<p> +This is what <c>/usr/include/asm/types.h</c> looks like on a AMD64 box: +</p> + +<codesample> +/* Common header file autogenerated by create_ml_includes in multilib.eclass */ +#ifdef __i386__ +#include <asm-i386/types.h> +#endif /* __i386__ */ + +#ifdef __x86_64__ +#include <asm-x86_64/types.h> +#endif /* __x86_64__ */ +</codesample> + +<p> +As you can see, this is just a wrapper that decides which file you need +depending on the the parameter <c>-D</c> given to gcc. You'll probably run into +some troubles if you try to compile something by hand and forget to append +<c>-D__x86_64__</c> to your <c>CFLAGS</c>. Of course, this is <b>not necessary</b> when +using portage. For an explanation, see the <uri link="::arch/amd64/#The ABI Variable"/> +section. +</p> + +</body> +</subsection> + +<subsection> +<title>The ABI Variable</title> +<body> + +<p> +Whenever portage builds something on amd64, it has to decide whether it should +be 32bit or 64bit. As stated in <uri link="::arch/amd64/#Headers and Multilib"/> +the <c>__i386__</c> or <c>__x86_64__</c> respectively, is needed in <c>CDEFINE</c>. +Also, gcc has to know what code it should produce, therefore <c>-m32</c> or <c>-m64</c> +must be appended to CFLAGS. This is done via <c>profile.bashrc</c>. All you need to do +if you want to build a package 32bit is to set <c>ABI=x86</c>. +</p> + +<p> +The details are shown in <c>make.defaults</c>: +</p> + +<codesample lang="ebuild"> +MULTILIB_ABIS="x86 amd64" +DEFAULT_ABI="amd64" + +CFLAGS_amd64="-m64" +LDFLAGS_amd64="-m elf_x86_64" +CHOST_amd64="x86_64-pc-linux-gnu" +CDEFINE_amd64="__x86_64__" +LIBDIR_amd64="lib64" + +CFLAGS_x86="-m32 -L/emul/linux/x86/lib -L/emul/linux/x86/usr/lib" +LDFLAGS_x86="-m elf_i386 -L/emul/linux/x86/lib -L/emul/linux/x86/usr/lib" +CHOST_x86="i686-pc-linux-gnu" +CDEFINE_x86="__i386__" +LIBDIR_x86="lib32" +</codesample> + +</body> +</subsection> + +</body> +</section> + +<section> +<title>Porting Notes</title> +<body> + +<subsection> +<title>Machine Word sizes</title> +<body> + +<p> +On AMD64, some types differ in size from x86: +</p> + +<table> + <tr> + <th> + Type + </th> + <th> + x86 (ILP32) + </th> + <th> + amd64 (LP64) + </th> + </tr> + <tr> + <ti> + <c>char</c> + </ti> + <ti> + 1 byte + </ti> + <ti> + 1 byte + </ti> + </tr> + <tr> + <ti> + <c>short</c> + </ti> + <ti> + 2 bytes + </ti> + <ti> + 2 bytes + </ti> + </tr> + <tr> + <ti> + <c>int</c> + </ti> + <ti> + 4 bytes + </ti> + <ti> + 4 bytes + </ti> + </tr> + <tr> + <ti> + <c>long</c> + </ti> + <ti> + <b>4 bytes</b> + </ti> + <ti> + <b>8 bytes</b> + </ti> + </tr> + <tr> + <ti> + <c>long long</c> + </ti> + <ti> + 8 bytes + </ti> + <ti> + 8 bytes + </ti> + </tr> + <tr> + <ti> + <c>pointer</c> + </ti> + <ti> + <b>4 bytes</b> + </ti> + <ti> + <b>8 bytes</b> + </ti> + </tr> + <tr> + <ti> + <c>float</c> + </ti> + <ti> + 4 bytes + </ti> + <ti> + 4 bytes + </ti> + </tr> + <tr> + <ti> + <c>double</c> + </ti> + <ti> + 8 bytes + </ti> + <ti> + 8 bytes + </ti> + </tr> + <tr> + <ti> + <c>long double</c> + </ti> + <ti> + 16 bytes + </ti> + <ti> + 16 bytes + </ti> + </tr> +</table> + +<p> +If you need an exact amount of space, don't use these types but the <c>uXX</c> and +<c>sXX</c> ones provided by <c>types.h</c>, where XX is the number of bits you need. +Switching to a type that is the same on both arches is not suggested since it's +not a clean solution and might cause problems with other arches. +</p> + +</body> +</subsection> + +<subsection> +<title>Casts</title> +<body> + +<p> +Many upstream developers assume that the length of a pointer is 4 bytes, which +can cause problems when programs do casts from <c>void *</c> to <c>int</c> and vice +versa. With GCC 3.4, this causes warnings, the compilation won't abort. If +you're lucky, your package works, but it's likely that you encounter +segmentation faults or strange behaviour. GCC 4.0 refuses to compile such code. +</p> + +</body> +</subsection> + +</body> +</section> + +</body> +</chapter> +</guide> diff --git a/archs/text.xml b/archs/text.xml new file mode 100644 index 0000000..e598a0e --- /dev/null +++ b/archs/text.xml @@ -0,0 +1,36 @@ +<?xml version="1.0"?> +<guide self="archs/"> +<chapter> +<title>Arch Specific Notes</title> +<body> + +<p> +This section provides a brief overview of various arch-specific issues. It is not +complete, and it is not a substitute for discussing any problems with the +relevant arch team. +</p> + +<note> +People who have worked with some other distributions may find Gentoo's +views on architecture support slightly unfamiliar. We do not follow Debian's +attempts to provide a standard set of packages at specific versions and install +it onto every platform <d/> rather, we simply attempt to provide whatever +happens to work best in any situation. +</note> +</body> + +<section> +<title>Contents</title> +<body> +<contentsTree/> +</body> +</section> +</chapter> + +<include href="alpha/"/> +<include href="amd64/"/> +<!--<include href="mips/"/> +<include href="sparc/"/> +<include href="x86/"/>--> + +</guide> diff --git a/hosted-projects/text.xml b/hosted-projects/text.xml new file mode 100644 index 0000000..55a6b8a --- /dev/null +++ b/hosted-projects/text.xml @@ -0,0 +1,166 @@ +<?xml version="1.0"?> +<guide self="hosted-projects/"> +<chapter> +<title>Hosted Projects</title> + +<body> +<p> +The following guidelines have been proposed for hosted projects in an attempt to +prevent a repeat of the <c>genkernel</c> disaster. +</p> + +<section> +<title>Documentation Requirement</title> +<body> + +<p> +All hosted projects should have decent, up to date user and developer +documentation. This documentation must be available <e>before the first release</e>, +and not left as "something we'll do later (honest)". +</p> + +<p> +Our documentation team are happy to help out with GuideXMLification, translation +etc. for the user documentation, but they <e>need</e> various things to do this: +</p> + +<ul> + <li> + Basic documentation to start with. + </li> + <li> + Basic information on the project or tool, such as: + <ul> + <li> + The goals + </li> + <li> + The design specification + </li> + <li> + An FAQ + </li> + </ul> + </li> + <li> + To be informed of any updates, in advance if at all possible <d/> this is to + avoid having out of date recommendations in the documentation. + </li> +</ul> + +<p> +Developer documentation is generally best left in the hands of the project +maintainers. +</p> + +</body> +</section> + +<section> +<title>Portability</title> +<body> + +<p> +Gentoo runs on a large number of architectures. This is one of our big +advantages over some other distributions. It is therefore important that any +tools are made with portability in mind, <e>even if you originally think that your +tool is only relevant for one arch</e>. It was this kind of assumption that meant +that <c>genkernel</c> had to be completely rewritten when it suddenly became +mandatory. +</p> + +<p> +In practice, this means the following: +</p> + +<ul> + <li> + Using a portable programming language <d/> no Java or C# for any Gentoo tools. + Bash, C and Python are good, especially since everyone already has those + installed. + </li> + <li> + Not making assumptions about the hardware or architecture. This covers various + things, depending upon the tool <d/> simple examples include: + <ul> + <li> + Not assuming that you are running on a 32bit little endian system. + </li> + <li> + Not assuming that all computers have a VGA text console, or indeed any + kind of graphics capability. + </li> + <li> + Not assuming that all computers use DOS disclabels. + </li> + </ul> + </li> + <li> + Not relying too strongly upon particular implementations of various tools, + except where it has been agreed that we will always use a particular + implementation of said tool (it is safe to use <c>GNU sed</c> extensions, for + example, but <e>not</e> <c>GNU find</c> extensions). + </li> +</ul> + +</body> +</section> + +<section> +<title>Open / Free</title> +<body> + +<p> +All hosted projects should use an appropriate open / free / libre license. +Typically this will be the GPL v2 for software, and the Creative Commons license +for documentation. However, reasonable exceptions can be made <d/> sometimes it +makes more sense to use the LGPL or a *BSD license, and for application-specific +projects going with the application's license may make more sense (the +<c>gentoo-syntax</c> package for <c>vim</c> uses the <c>vim</c> license, for example). +</p> + +</body> +</section> + +<section> +<title>Accessible</title> +<body> + +<p> +Projects should be accessible to users with disabilities. Simple examples of how +to go about this include: +</p> + +<ul> + <li> + Not relying solely upon colour to convey information. + </li> + <li> + Providing textual descriptions for any images. + </li> + <li> + Providing clear captions for dialogs, buttons, form fields and so on. + </li> +</ul> + +<p> +Good places to look for further hints include: +</p> + +<ul> + <li> + <uri link="http://developer.gnome.org/projects/gap">GNOME Accessibility + Project</uri> + </li> + <li> + <uri link="http://www.w3.org/WAI/Resources/#gl">W3C Web Accessibility + Initiative Guidelines</uri> + </li> +</ul> + +</body> +</section> + +</body> +</chapter> +</guide> @@ -43,5 +43,7 @@ section for how to get started. <include href="function-reference/"/> <include href="eclass-reference/"/> <include href="tools-reference/"/> +<include href="hosted-projects/"/> +<include href="archs/"/> <include href="appendices/"/> </guide> |