[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Todo for libposix branch?
Re: Todo for libposix branch?
Sun, 29 May 2011 13:01:05 +0200
On 2011-05-03 you wrote:
> Is there a public todo for the libposix branch? If so, could it go in
> the branch somewhere visible? If not, is there any way I can help
> gather up the material for one? I'm keen now to see libposix a
> reality, so I'd like to see what still needs to be done to get it in
I've combined the answers by Bruce and me and put them into a file
'STATUS-libposix'. Such status of work-in-progress would better be stored
and modified in a wiki, but Savane does not offer wikis, AFAIK. So I'm
storing it in gnulib's git.
Please keep this file up to date as progress goes on!
=============================== STATUS-libposix ===============================
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:
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
1) Allow generate header files to coexist without shadowing each other.
Half of the work has been done, but not yet pushed.
2) Allow using libgnu's file name in module descriptions.
3) iconv_open's file file list
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
More discussion needed
5) Installable headers
Patch to be rewritten to use nobase_nodist_include_HEADERS,
also need to add an Automake conditional to distinguish libposix from
Also see whether the Automake bug can be fixed.
6) libposix subdirectory
7) use git-version-gen for version numbering
Patch to be revised.
Status: A majority of the issues have been handled.
Obsolete modules (free, memcpy) can be ignored.
To be done:
Status: No real plan exists.
In memoriam John Penry <http://en.wikipedia.org/wiki/John_Penry>
Re: Todo for libposix branch?, Bruno Haible, 2011/05/03
Re: Todo for libposix branch?,
Bruno Haible <=
- Re: Todo for libposix branch?, (continued)
- Re: Todo for libposix branch?, Bruce Korb, 2011/05/03
- Re: Todo for libposix branch?, Gary V. Vaughan, 2011/05/04
- Re: Todo for libposix branch?, Reuben Thomas, 2011/05/04
- Re: glob-libc.h not installed, Bruce Korb, 2011/05/04
- Re: glob-libc.h not installed, Reuben Thomas, 2011/05/04
- Re: glob-libc.h not installed, Reuben Thomas, 2011/05/08
- Re: glob-libc.h not installed, Bruce Korb, 2011/05/09
- Re: glob-libc.h not installed, Reuben Thomas, 2011/05/25
- Re: glob-libc.h not installed, Bruce Korb, 2011/05/25