libk  Check-in [8d6d792515]

Overview
Comment:add documentation compilation
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 8d6d792515273e92a2fa145eeb768cb2555481babc7b0c5b172f32ac78e75024
User & Date: lexi on 2019-08-19 22:40:04
Other Links: manifest | tags
Context
2019-08-19
23:57
add detection loop for syscall headers check-in: c7732c41c9 user: lexi tags: trunk
22:40
add documentation compilation check-in: 8d6d792515 user: lexi tags: trunk
05:42
switch over to new build mechanism and formally deprecate makefiles check-in: 34c625a47b user: lexi tags: trunk
Changes

Modified build.sh from [e19ff3649f] to [669569b504].

    47     47   	*) say "cannot determine correct binary format to use for target $target"; exit 1;;
    48     48   esac
    49     49   
    50     50   # first, we establish the
    51     51   # parameters of the build
    52     52   has cc && _cc=cc
    53     53   has clang && _cc=clang 
    54         -has gcc && _cc=gcc
           54  +has gcc && _cc=gcc # prefer gcc
    55     55   cc=${cc:-$_cc}
    56     56   has m4 && _m4=m4
    57     57   m4=${m4:-$_m4}
    58     58   has nasm && asm=nasm
    59         -has yasm && asm=yasm
           59  +has yasm && asm=yasm # prefer yasm
    60     60   export gen=${gen:-gen}
    61     61   library=${libkind:-static} # {static|shared|both}
    62     62   
           63  +doc=${doc:-yes}
           64  +export doc_html=${doc_html:-yes}
           65  +export doc_pdf=${doc_pdf:-yes}
           66  +export doc_man=${doc_man:-yes}
           67  +
    63     68   case $library in
    64     69   	static) build_static_library=yes
    65     70   	        build_shared_library=no;;
    66     71   
    67     72   	shared) build_static_library=no
    68     73   	        build_shared_library=yes;;
    69     74   
................................................................................
   129    134   
   130    135   # generate errno tables
   131    136   grep -h "#[ 	]*define[ 	]\+E" $p_headers_errno | sed 's;^#[\t ]*define[\t ]\+\(E[A-Z0-9]\+\).*$;k_platform_error_\1 \1;' > $gen/error_names.tbl
   132    137   cat $p_headers_errno $gen/error_names.tbl | cpp -P >$gen/error_numbers.tbl
   133    138   awk -f arch/errtbl.awk <$gen/error_numbers.tbl >$gen/error_table.h
   134    139   
   135    140   # generate symbol tables for error handling functions
   136         -mkdir -p $out/k
          141  +mkdir -p "$out/k"
   137    142   awk -f global/gen-conds.awk <global/modules >$out/k/internal.egroup.h
   138    143   awk -f global/gen-ident.awk <global/modules >$gen/internal.ident.c
   139    144   comp_co $gen/internal.ident.c $out/internal.ident.o
   140    145   
   141    146   # first pass: copy all headers into place,
   142    147   # including ones we need to generate
   143    148   
................................................................................
   153    158   		comp_mac "$h" "$out/k/$dest"
   154    159   	done
   155    160   done
   156    161   
   157    162   # second pass: generate manpage, html, and pdf
   158    163   # versions of the documentation from the md src
   159    164   
   160         -mkdir -p $out/doc/{man,html,pdf}
   161         -global/build-manpage.sh libk.md
   162         -for mod in ${modules[@]}; do
   163         -	for doc in $(scan $mod '*.md'); do
   164         -		base="$(basename $doc)"
   165         -		stem="${base%%.md}"
   166         -		global/build-manpage.sh "$doc"
   167         -		global/build-html.sh "$doc"
   168         -		global/build-pdf.sh "$doc"
          165  +if test "$doc" = "yes"; then
          166  +	global/build-manpage.sh libk.md
          167  +	for mod in ${modules[@]}; do
          168  +		for doc in $(scan $mod '*.md'); do
          169  +			base="$(basename $doc)"
          170  +			stem="${base%%.md}"
          171  +			global/build-manpage.sh "$doc"
          172  +		done
   169    173   	done
   170         -done
          174  +fi
   171    175   
   172    176   # third pass: compile sources and save the
   173    177   # resulting object files to $out, tracking
   174    178   # which is a runtime or function unit. exe's
   175    179   # will not be compiled until a later pass
   176    180   
   177    181   fn_objects=()

Deleted global/build-html.sh version [045bd446a1].

     1         -#!/usr/bin/env bash
     2         -(test -d global && test -f build.sh) || {
     3         -	echo >&2 "($0) run $me from root of libk source directory"
     4         -	exit 1
     5         -}
     6         -
     7         -. global/common.sh
     8         -reqpack cmark "generate documentation"
     9         -
    10         -say "facility under construction"
    11         -exit 0

Modified global/build-manpage.sh from [b795aa8a1c] to [790e90297c].

     2      2   (test -d global && test -f build.sh) || {
     3      3   	echo >&2 "($0) run $me from root of libk source directory"
     4      4   	exit 1
     5      5   }
     6      6   
     7      7   . global/common.sh
     8      8   reqpack cmark "generate documentation"
     9         -
            9  +check gen "a directory for generated build dependencies"
    10     10   
    11     11   file="$1"
    12     12   filename="$(basename "$file")"
    13     13   stem=${filename%%.md}
    14         -mandest="$out/doc/man"
    15         -section=${section:-4}
    16         -out="$mandest/$stem.$section"
           14  +
           15  +mandest=${out_manpage:-"$out/doc/man"}
           16  +htmldest=${out_html:-"$out/doc/html"}
           17  +pdfdest=${out_pdf:-"$out/doc/pdf"}
           18  +
           19  +section=${manual_section:-4}
           20  +man="$mandest/$stem.$section"
           21  +html="$htmldest/$stem.html"
           22  +pdf="$pdfdest/$stem.pdf"
           23  +fmt="$gen/$stem.tmp"
           24  +
    17     25   desc_rec="$(grep -m1 "^$stem:" global/modules)"
    18     26   if test "$desc_rec" != ""; then
    19     27   	desc=" - $(echo $desc_rec | cut -d: -f4)"
    20     28   else
    21     29   	desc=""
    22     30   fi
    23     31   date="$(date -r"$file" "+%d %A %Y")"
    24     32   
    25         -mkdir -p "$mandest"
    26     33   
    27         -echo  >"$out" ".TH ${stem^^} \"$section\" \"$date\" \"hale.su libk [r$build]\" \"modules\""
           34  +echo  >"$fmt" ".TH ${stem^^} \"$section\" \"$date\" \"hale.su libk [r$build]\" \"modules\""
    28     35   
    29         -echo >>"$out" ".SH NAME"
    30         -echo >>"$out" "$stem$desc"
    31         -echo >>"$out" ".SH SYNOPSIS" 
           36  +echo >>"$fmt" ".SH NAME"
           37  +echo >>"$fmt" "$stem$desc"
           38  +echo >>"$fmt" ".SH SYNOPSIS" 
    32     39   
    33     40   dhead=$(grep -m1 -n "^# description$" "$file")
    34     41   if test $? -eq 0; then
    35     42   	descline=$(echo "$dhead" | cut -d: -f1)
    36     43   	offset=1
    37     44   else
    38     45   	descline=$(grep -m2 -n "^#" "$file" | tail -n1 | cut -d: -f1)
    39     46   	offset=0
    40     47   fi
    41     48   
    42         -tail -n+2 $file | head -n$(expr $descline - 2) | cmark -t man >>"$out"
           49  +tail -n+2 $file | head -n$(expr $descline - 2) | cmark -t man >>"$fmt"
           50  +
           51  +echo >>"$fmt" ".SH DESCRIPTION"
           52  +
           53  +tail -n+$(expr $descline + $offset) "$file"  | cmark -t man >> "$fmt"
           54  +
           55  +test "$doc_html" = "yes" && {
           56  +	mkdir -p "$htmldest"
           57  +	groff -Thtml -Kutf8 -m man "$fmt" > "$html"
           58  +	say "wrote html page for $stem to $html"
           59  +}
    43     60   
    44         -echo >>"$out" ".SH DESCRIPTION"
           61  +test "$doc_pdf" = "yes" && {
           62  +	mkdir -p "$pdfdest"
           63  +	groff -Tpdf  -Kutf8 -m man "$fmt" > "$pdf"
           64  +	say "wrote pdf for $stem to $pdf"
           65  +}
    45     66   
    46         -tail -n+$(expr $descline + $offset) "$file"  | cmark -t man >> "$out"
           67  +test "$doc_man" = "yes" && {
           68  +	mkdir -p "$mandest"
    47     69   
    48         -if has gzip; then
    49         -	gzip -f "$out"
    50         -	out="$out.gz"
    51         -fi
           70  +	if has gzip; then
           71  +		man="$man.gz"
           72  +		gzip -c -f "$fmt" > "$man"
           73  +	else
           74  +		mv "$fmt" "$man"
           75  +	fi
    52     76   
    53         -say "wrote manpage for $stem to $out"
           77  +	say "wrote manpage for $stem to $man"
           78  +}

Deleted global/build-pdf.sh version [045bd446a1].

     1         -#!/usr/bin/env bash
     2         -(test -d global && test -f build.sh) || {
     3         -	echo >&2 "($0) run $me from root of libk source directory"
     4         -	exit 1
     5         -}
     6         -
     7         -. global/common.sh
     8         -reqpack cmark "generate documentation"
     9         -
    10         -say "facility under construction"
    11         -exit 0

Modified libk.md from [debe7693f6] to [a982938576].

     1      1   # libk
     2      2   
     3      3   libk is intended as a modernized replacement *(not* reimplementation) for libc.
     4      4   
     5         -## manifesto
            5  +# manifesto
     6      6   
     7      7   normally, all C binaries (and binaries from other languages, depending on the platform) use a combination of libraries to get things done: POSIX libraries (interfaces common to UNIX-like operating systems) and libc, the C standard library. unlike POSIX, libc is part of the C language -- it's a standardized interface to various critical parts of the operating system, things like IO, system clock access, random number generation, and more.
     8      8   
     9      9   it's also a piece of shit.
    10     10   
    11     11   libc is ancient, and it shows. it contains decades worth of cruft, masses of different interfaces with completely different design, horrible hacks to get around the fundamental shifts in basic computer architecture that have occurred over the past half-century, and vendor-specific extensions that make porting code a nightmare. using it is painful, tedious, error-prone, and unsafe. for various reasons, there are many different implementations of libc, but all of them have that same broken, bloated interface in common. as far as i can tell, there are been no serious attempts to create an actual *alternative* to libc - a new system interface that takes into account the decades of painful lessons we programmers have learned since the heydays of UNIX.
    12     12   
    13     13   hence, libk.
    14     14   
    15     15   libk aims to offer a better, safer, and most importantly, less unpleasant foundation for modern code in C or any other language. it also aims to be much smaller, simpler, and faster than glibc to build so that there's no arduous bootstrapping process for new architectures.
    16     16   
    17     17   currently, the only dependency on libc in any form is `arch/typesize.c`, a small binary tool which uses libc IO routines to print type information it calculates; however, this could also be augmented to use POISX IO routines, or even potentially libk IO routines to remove any external dependency at all -- the work would be nontrivial, but fully feasible. further, the file it creates can also _in extremis_ be created by hand. the final compiled libc binaries and headers do not depend on or reference libc in any way; typesize is only a makedepend.
    18     18   
    19         -# goals
           19  +## goals
    20     20   
    21     21   libk's goals are far-reaching, and suggestions are welcome. note however that libk is *not* intended to be a kitchen-sink library like libiberty. it's meant to do one thing, and to it well: to provide an easy- and pleasant-to-use foundation for modern open source projects. below is a list of some of the project's major goals.
    22     22   
    23     23    1. **IO.** libc's basic input/output mechanisms are dreadful, built at entirely the wrong level of abstraction. libk is intended to make many more primitives available to the user, and offer a sliding scale of abstraction so libk is suitable for a wide range of needs.
    24     24    2. **file manipulation.** libc's file manipulation primitives are a relic of a bygone age and in dire need of upgrading.
    25     25    3. **terminal manipulation.** libc has no provision for simple output formatting, a task that requires a combination of ANSI codes and in some cases pty manipulation with POSIX APIs, both of which are somewhat dark wizardry. this situation forces many innocent coders to drag in the entire unholy bulk of the aptly named library `ncurses`, much of whose code has been utterly obsolete for the last twenty years and whose API is one of the most singularly hateful ones in existence. libk therefore should offer a simple, straightforward way to do gracefully-degrading terminal sorcery.
    26     26    4. **memory management.** the single memory management function `malloc()` provided by libc is absolutely pitiful. this is 2019. modern applications have much more exotic allocation needs, and a standard library should offer a range of allocators and management techniques, as well as abstract pointer objects so that pointers to objects of different allocation types (including static or stack allocation!) can be mixed freely and safely.
    27     27    5. **intrinsic reentrancy.** because *jesus christ,* libc.
    28     28    6. **interprocess communication.** libc offers no useful IPC abstractions over the paltry array of tools POSIX &co. give us to work with. we can do better.
    29     29    7. **tooling.** libk is intended as more than just a library. it's also intended to work with some basic tooling to automate tasks that current binary tooling is inadequate for -- for instance, embedding binary data into a program binary. (see module [kgraft](kgraft))
    30     30    8. **modularity.** libk is not part of the C specification and it isn't always going to be practical for developers to expect the entire library to be present on the end-user's computer. so libk is designed to be usable in many different ways -- as a traditional library, as a static library, in full form or with only components needed by the developer, to be distributed either on its own or as part of a binary.
    31     31    9. **compatibility.** code that links against libk should be able to compile and run on any operating system. in the ideal case (Linux or FreeBSD) it will be able to do so without touching any other system libraries; for less ideal environments like Windows, libk will when necessary abstract over system libraries or libc itself.
    32     32    10. **sane error-handling.** every time you type `errno` god murders a puppy.
           33  + 11. **ease of distribution.** libk should enable to user to create completely static binaries, free of any local dependency and trivial to distribute.
    33     34   
    34     35   # dependencies
    35     36   
    36     37   libk is designed to be as portable and depedency-free as possible. ideally, it will be possible to compile code against libk using nothing but libk itself.
    37     38   
    38         -compiling libk is also designed to be as easy as possible. it has only two external dependencies, the macro processor [m4], needed for compile-time header generation, and the [GNU make] utility, whose advanced features are needed to perform the relatively complex task of building all of libk from the ground up. 
           39  +compiling libk is also designed to be as easy as possible. it has only two external dependencies, the macro processor [m4], needed for compile-time header generation, and optionally the [commonmark] compiler `cmark`, which is only needed if you wish to typeset the documentation in manpage, html, or pdf format. this process also requires `groff`, but `groff` is a standard part of most UNIX systems.
    39     40   
    40     41    [m4]: http://www.gnu.org/software/m4
    41         - [GNU make]: http://www.gnu.org/software/make
           42  + [commonmark]: http://www.commonmark.org/
    42     43   
    43     44   a different macro processor, gpp, was used in early versions of libk, however, it was so obscure and took so much overly fragile infrastructure to make it work that the cleaner syntax just wasn't worth it; i've since deleted the gpp infra and ported the macro files to m4.
    44     45   
    45     46   # naming conventions
    46     47   
    47     48   one of the most frustrating things about libc is its complete and total *lack* of a naming convention. in C, every function and global is injected into a single global namespace, including macros. this means that every libc header you include scatters words all over that namespace, potentially clobbering your function with a macro!
    48     49   
................................................................................
    65     66    3. capital letters are only used in macro prefixes.
    66     67    4. low-level function names are prefixed with the API they call into. for example, the function that performs the POSIX syscall `write` is named `kio_posix_fd_write`. a wrapper around the Windows function `CreateProcess()` might be called `kproc_win_createprocess`.
    67     68   
    68     69   ## atoms
    69     70   
    70     71   libk uses the concept of "atoms" (small, regular strings of text) to standardize common references, such as operating systems or processor architectures.
    71     72   
    72         -### operating systems
           73  +**operating systems**
    73     74   
    74     75   these atoms will be used to reference operating systems.
    75     76   
    76     77    * Linux: `lin`
    77         -  1. aaaa
    78     78    * Haiku: `hai`
    79     79    * Android: `and`
    80     80    * FreeBSD: `fbsd`
    81     81    * NetBSD: `nbsd`
    82     82    * OpenBSD: `obsd`
    83     83    * Darwin/Mac OS X/iOS: `dar`
    84     84    * MS-DOS: `dos`
    85     85    * FreeDOS: `fdos`
    86     86    * Windows: `win`
    87     87    * Windows MinGW: `mgw`
    88     88   
    89         -### file extensions
           89  +**file extensions**
    90     90   
    91     91    * C function implementations: `*.c`
    92     92    * C module headers: `*.h`
    93     93    * ancillary C headers: `*.inc.h`
    94     94    * assembly code: `*.s`
    95     95   
    96         -### arches
           96  +**arches**
    97     97   
    98     98   these atoms will be used to reference particular system architectures. these will mostly be used in the filenames of assembly code.
    99     99    * Intel/AMD x86: `x86`
   100    100    * ARM: `arm` (aarch64 is specified by `os=arm bits=64`)
   101    101    * MIPS: `mips`
   102    102    * Itanium: `ia64` (no bits)
   103    103    * PowerPC: `ppc`
................................................................................
   142    142   
   143    143   each module may contain any number of files of the name `*.exe.c`. this files will be treated as *tools* by the build system and compiled as executables, rather than libraries. they should be compiled to `out/$module.$tool`
   144    144   
   145    145   the repository root and each module may also contain the directory `misc`. this directory may be used to store miscellaneous data such as ABI references, developer discussions, and roadmaps. if the `misc` directory is deleted, this must not affect the library or build system's function in any way - that is, nothing outside a `misc` folder may reference a `misc` folder or anything inside it, including documentation. the `misc` directory should be removed when its contents are no longer needed. in most cases, the repository wiki and forum should be used instead of the `misc` folder.
   146    146   
   147    147   the folder `arch` in the root of the repository contains syscall tables and ABI implementations for various architectures.
   148    148   
   149         -## build sysem
          149  +# build system
   150    150   
   151    151   libk uses a very simple build system. the entire project is built with the `build.sh` script in the project root. `build.sh` need not be modified so long as all you're adding is functions, runtime stubs, headers, documentation files, or macro files in line with the standard naming convention. it will need to be modified to add or remove modules. it does not track dependencies, recompiling the entire project in one fell swoop. while in theory this could be slow and inefficient, in practice, it's not meaningfully slower on the average run than the old make-based system was.
   152    152   
   153    153   the shell-based build system was chosen for a number of reason. firstly, libk originally used a GNU make-based build system, but this was unwieldy and unreliably - make simply does not have the necessary capabilities to build a project of this nature. the original build system relied heavily on recursion, which is impossible to use while preserving idempotency. multithreaded building was likewise impossible.
   154    154   
   155    155   relying on make also had a number of subtler downsides. GNU make's capacities vary significantly across versions, and not all users will necessarily have access to the correct version in their repos. even a version as recent as make 4.1 couldn't build a project that build without issue in 4.2. given that libk is explicitly intended to be widely portable, this variance was alarming. make is also very indirect - it's a pain in the ass to tell it what to do sometimes, and it's well nigh on impossible to decipher the intricate way in which a sufficiently complex set of makefiles interlocks. this is both user- and developer-hostile. by contrast, a simple, linear build script with clearly delineated functions makes the build process much easier to understand, and therefore to tweak should a user need to modify some aspect of the process to compile `libk` on her system.
   156    156   
   157    157   finally, make simply has a smaller install base than `bash`. with the `build.sh` build system, more people can successfully build libk with less effort.
   158    158   
   159         -any time you make a change to the build script, always specify precisely what changed in your commit log and what affects this might have on the surrounding code. be sure to comment any new code as thoroughly as you can. the goal is that anyone who is familiar with bash should be able to learn the build process simply by reading `build.sh`.
          159  +any time you change build script, always specify precisely what changed in your commit log and what affects this might have on the surrounding code. be sure to comment any new code as thoroughly as you can. the goal is that anyone who is familiar with bash should be able to learn the build process simply by reading `build.sh`.
          160  +
          161  +## build process
          162  +
          163  +to build libk, you must invoke `build.sh` with the proper parameters. at minimum you must set the following environment variables:
          164  +
          165  + * `os={atom}` - an atom representing the operating system you are building libk for
          166  + * `arch={atom}` - an atom representing the processor architecture you are building libk for
          167  + * `bits={atom}` - if your processor has multiple variants with different word lengths (such as x86-32 vs. x86-64), specify the word length in this variable; otherwise, leave it unset.
          168  +
          169  +further optional variables may be set to control the build process and determine what targets it produces.
          170  + * `library=static {static|shared|both}` - this variable controls whether the build process will produce `libk.a`, `libk.so`, or both.
          171  + * `out=out {path}` - an alternate path to store build artifacts in
          172  + * `gen=gen {path}` - an alternate path to store generated source in
          173  + * `cc=<autodetect> {executable}` - the compiler to compile C sources with
          174  + * `m4=<autodetect> {executable}` - the m4 binary to compile the macro sources with
          175  + * `asm=<autodetect> {executable}` - the assembler to assemble the assembly listings with. it must take Intel-syntax input and handle nasm-style macros. only `yasm` and `nasm` are likely to be viable.
          176  + * `doc=yes {yes|no}` - whether to typeset the documentation (very slow with all three formats set to "yes")
          177  + * `doc_html=yes {yes|no}` - enable or disable html output of the documentation
          178  + * `doc_pdf=yes {yes|no}` - enable or disable pdf output of the documentation
          179  + * `doc_man=yes {yes|no}` - enable or disable manpage output of the documentation
          180  +
          181  +two other shell scripts complete the build system:
          182  + * `install.sh` - installs compiled libraries, objects, documentation, and headers into the appropriate directories.
   160    183   
   161    184   # design principles
   162    185   
   163    186   there are four overriding principles that guide the design of libk.
   164    187   
   165    188    1. it should be easy to write code that uses it.
   166    189    2. it should be easy to read code that uses it.
................................................................................
   182    205   		rule_kind_undialectical,
   183    206   		rule_action_expropriate,
   184    207   		rule_target_bourgeoisie
   185    208   	};
   186    209   
   187    210   this makes code much more legible and has the added benefit of making the definitions easier to expand at a later date if new functionality is needed without breaking the API or ABI.
   188    211    
   189         -## build process
   190         -
   191         -to build libk, you must invoke `build.sh` with the proper parameters. at minimum you must set the following environment variables:
   192         -
   193         - * `os={atom}` - an atom representing the operating system you are building libk for
   194         - * `arch={atom}` - an atom representing the processor architecture you are building libk for
   195         - * `bits={atom}` - if your processor has multiple variants with different word lengths (such as x86-32 vs. x86-64), specify the word length in this variable; otherwise, leave it unset.
   196         -
   197         -further optional variables may be set to control the build process and determine what targets it produces.
   198         - * `library=static {static|shared|both}` - this variable controls whether the build process will produce `libk.a`, `libk.so`, or both.
   199         - * `out=out {path}` - an alternate path to store build artifacts in
   200         - * `gen=gen {path}` - an alternate path to store generated source in
   201         - * `cc=<autodetect> {executable}` - the compiler to compile C sources with
   202         - * `m4=<autodetect> {executable}` - the m4 binary to compile the macro sources with
   203         - * `asm=<autodetect> {executable}` - the assembler to assemble the assembly listings with. it must take Intel-syntax input and handle nasm-style macros. only `yasm` and `nasm` are likely to be viable.
   204         -
   205         -two other shell scripts complete the build system:
   206         - * `install.sh` - installs compiled libraries, objects, documentation, and headers into the appropriate directories.
   207         -
   208         -## authors
          212  +# authors
   209    213   
   210    214   so far, this is a one-woman show. contributions are welcome however.
   211    215   
   212    216    * lexi hale <lexi@hale.su>
   213    217   
   214         -## caveats
          218  +# caveats
   215    219   
   216    220   the main coder, lexi hale, is first and foremost a writer, not a coder. this is a side-project of hers and will remain so unless it picks up a significant amount of attention.
   217    221   
   218    222   while MRs adding support for Windows, OS X, and other operating systems will be gratefully accepted, the maintainer is a Linux and FreeBSD developer, will not be writing such support infrastructure herself, and has limited ability even to vet code for those platforms.
   219    223   
   220         -## license
          224  +# license
   221    225   
   222    226   libk is released under the terms of the [GNU AGPLv3](LICENSE). contributors do not relinquish ownership of the code they contribute, but agree to release it under the same terms as the overall project license.
   223    227   
   224    228   the AGPL may seem like an inappropriately restrictive license for a project with such grandiose ambitions. it is an ideological choice. i selected it because libk is intended very specifically as a contribution to the *free software* community, a community that i hope will continue to grow at the expense of closed-source ecosystems. i have no interest in enabling people or corporations to profit from keeping secrets, especially not with my own free labor (or anyone else's, for that matter).
   225    229   
   226    230   if you disagree with this philosophy, you are welcome to continue using libc.
   227    231   
   228         -## what does the k stand for?
          232  +# what does the k stand for?
   229    233   
   230    234   nothing. it was chosen in reference to libc - the letter C was part of the original roman alphabet, while K was added later by analogy to the Greek kappa ‹κ›. in my native language, the older letter ‹c› can make a number of different sounds based on context, including [k] and [s], while ‹k› is fairly consistently used for the sound [k]. and for orthographical reasons, [k] is often represented by the digraph ‹ck› - that is, a C followed by a K. hopefully the analogies are obvious.
   231    235   
   232    236   this project has nothing to do with KDE.