Re: Todo for libposix branch?

[Gary V. Vaughan]

Hi Reuben, Bruce,

On Tue, May 03, 2011 at 04:56:33PM -0700, Bruce Korb wrote:
> On 05/03/11 15:45, Reuben Thomas wrote:
> >Is there a public todo for the libposix branch? If so, could it go in
> >the branch somewhere visible?

It's all in the mailing list archives, but summarizing the current
state of the unresolved threads into a committed TODO seems to me
like a useful thing to have.

> >If not, is there any way I can help gather up the material for one?

Sure, list archive archaeology and thread summary in a TODO file as
a patch would be awesome!

> >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
> >master.

Me too.  But someone needs to do the work and push the patches forward.
I burnt out on the cool reception of the painstaking rewrite of bootstrap
I made, and have many other commitments to juggle. I'd be very happy to
commit any progress you make to the libposix branch if you don't have a
commit bit of course :)

> 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.

I already submitted a huge comprehensive list of build problems with
libposix or gnulib modules needed by libposix to the list quite some time
ago.  I don't have the time or expertise to resolve them, though I'm still
more than willing to perform further tests, or rerun particular tests in
more detail for anyone that does have the time and expertise to diagnose
the underlying problems.

        http://lists.gnu.org/archive/html/bug-gnulib/2010-10/msg00278.html

>  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.
> 
> I've done this with a tiny example project I have, but I do not
> have access to a wide variety of platforms (Gary?).

See the many test failures I provoked in the thread linked above.

If anyone is interested, I'll merge current gnulib HEAD into libposix
branch as a base for further work.

> Thank you for your interest!  With nobody having tested the distro tarball,
> it becomes a lower priority thing for me. :)

One of my personal projects relies critically on an installed libposix,
though I have a long way to go before that becomes the stalling point
for progress.  That is, I will get to it eventually, but if anyone else
feels more urgency than me, the process of massaging libposix back into
master can happen A LOT quicker than if it's left entirely to my schedule :)

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

pgp9d5Pu0MFzT.pgp
Description: PGP signature