From 264ebf0e8b8760ee5434d35a3a9b0d3bc4810eb7 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Sun, 29 May 2011 13:00:39 +0200 Subject: [PATCH] Status of work-in-progress around libposix. (cherry picked from commit fdc9e6c9f8cf6afe33a6fa114c536750f16b459b) --- STATUS-libposix | 127 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 127 insertions(+) create mode 100644 STATUS-libposix diff --git a/STATUS-libposix b/STATUS-libposix new file mode 100644 index 000000000..58b7506d8 --- /dev/null +++ b/STATUS-libposix @@ -0,0 +1,127 @@ +Status for libposix +=================== + +This file documents the status of work-in-progress. +No ChangeLog entries are needed for this file. + +Status for the libposix branch +------------------------------ + +Bruce Korb says: + +I think a real big step in libposix is to get a little experience with it. +There are also some few little nits pointed out in the discussions that +need some careful consideration, but some experience in using it would +be good, too. The intended/expected usage is along the lines of: + +1. configure, build and install the thing. Perhaps from: + http://autogen.sourceforge.net/data/ + or roll your own, but the distribution should be there, I think. + +2. fiddle a project to detect that it is "sufficiently recent" to + cover the needs of this unnamed project. That is an interesting + issue, though: the concept behind "configure" is that you do + feature tests rather than version testing. However, if you choose + to not test the version of libposix and test the features you + need of libposix, then I have an extremely difficult time trying + to understand the point of libposix -- you are back to running + a bunch of feature tests that take too long. Testing for a + libposix current as of some marker (version number or date) + seems right to me, though there are some caveats to consider + regarding "retired" POSIX features. + + Anyway, the "fiddle a project" should boil down to testing + for libposix in some way and then dying if it is not up to snuff. + +3. configure, build, test, install and test installation of said project. + + +TODO list for master +-------------------- + +Bruno Haible says: + +1) ... 7) + proposed by Gary in the thread starting at + [PATCH 0/7] contents of topic/libposix for merge to master + in + +1) Allow generate header files to coexist without shadowing each other. + + + Discussion: + + + Half of the work has been done, but not yet pushed. + + + +2) Allow using libgnu's file name in module descriptions. + + + Discussion: + + + + Discussion: + + + libposix needs to install only selected headers, not all of them. Let the + script look at the 'Include:' section of each module description. + +4) Module libposix + + + Discussion: + + More discussion needed + +5) Installable headers + + + Discussion: + + Patch to be rewritten to use nobase_nodist_include_HEADERS, + also need to add an Automake conditional to distinguish libposix from + other projects. + Also see whether the Automake bug can be fixed. + + +6) libposix subdirectory + + + Discussion: + + +7) use git-version-gen for version numbering + + + Discussion: + + + Patch to be revised. + +8) Licensing + + + Status: A majority of the issues have been handled. + Obsolete modules (free, memcpy) can be ignored. + To be done: + getcwd + faccessat + fdopendir + linkat + mkfifoat + openat + readlinkat + renameat + symlinkat + utimensat + +9) Versioning + + + Status: No real plan exists. -- 2.11.0