Re: installable gnulib library

[Bruce Korb]

Hi Gary,

>> Of course it is.  To properly understand 150+ lines of usage text
>> one needs to read the source and understand the intimate details
>> of libtool and autoconf.  I keep meaning to, but life gets in the way.
> 
> Are you implying that libtool is complicated? ;)

Not at all.  It is, but I was saying that gnulib-tool is complicated:
$ ./gnulib-tool --help|wc -l
158

> I can't think of a way to make this completely transparent.  At some point
> you have to tell gnulib-tool that you are using an installed libposix in
> place of some selection of gnulib modules, so you might as well take the
> path of least resistance, and implement --avoid-posix rather than some
> complex solution.

You are likely right.  I'd like to put some effort into avoiding that.

>>> AC_INIT([libposix], [20101010], address@hidden)
>>
>> The version will need to be computed :)
> 
> Did I get the calculation wrong?  I am UTC+8, so it was right for me at the
> time I wrote it ;)

No.  But is is wrong now.  Besides, we've already made the (reasonable)
agreement that the version number is based upon the first date found
in the ChangeLog.  If the ChangeLog changes, the version has to change.
It has to be scripted.

> But seriously, gnulib already provides the tools to do this (git-version-gen
> and .tarball-verion), so let's use the existing rather than invent something
> new.

There is no script name "tarball-version", so I don't know what that is.
The reason for the date version is to make it easy for client projects
to say, "I know that what I need was added by October 10, 2010, so the
libposix version must be more recent than 20101010 -- though I would really
prefer to spell it 2010.10.10 because it is so much easier to read and
it is compatible with the syntax version parsers are expecting.

Anyway, done for the night.  Regards, Bruce