Re: installable gnulib library

[Bruce Korb]

Hi Gary,

On Fri, Oct 8, 2010 at 8:48 PM, Gary V. Vaughan <address@hidden> wrote:
>> 400 lines of intense shell script later, ...
>
> With only a very cursory look at the implementation - how come you don't
> just invoke gl_EARLY and gl_INIT and let the gnulib machinery take care of
> including all the macros?

Because the "configure.ac" is built by gnulib-tool.  I run this command:
   gnulib-tool --libtool --lib=libposix \
      opts="--create-testdir --source-base=lib --dir=libposix
and edit the result as little as I can.  The configure.ac edits are:

1. create AC_INIT, AC_CONFIG_SRCDIR and AC_CONFIG_MACRO_DIR
     macros
2. delete the initial lines of configure.ac and append to the text above,
    with the following changes:
    local sedcmd="
        1,/^AC_INIT(/d
        s/dnl .*//
        /^\$/d
        /^#/d
        s/gllib/${TARNAME}/g
        s/LIBGNU_L/${UC_NAME}_L/g
        s/^AM_CONDITIONAL.*LIBTOOL.*/AC_PROG_LIBTOOL/
        /^gl_cond_libtool/d
        /^AC_OUTPUT/i\\
AC_CONFIG_FILES([${mk_pc}:${mk_src}])"

  In English:
  a) remove AC_INIT
  b,c,d) remove comments
  e,f) change gllib/LIBGNU to libposix
  g,h) make libtool unconditional
   i) add my generate-libtool.pc script to configured files

In fact, the thing *does* use gl_INIT -- the configure.ac defines it.
My guess at the reasoning for what I see is that the resulting text
is completely independent of gnulib.  It has been "bootstrapped".
I think that's the right thing.

> I have been following the thread with interest, but until just recently
> you were bumping up against gnulib limitations that stopped you building
> it, so I had not yet tried it for myself.

I got past that days ago and I'm now part of the instant communications
culture.  :-D

> Bootstrapped with Autoconf 2.59?!? ;)

Oh, yeah, something fubar-ed my libraries and all my browsers started
assert-failing.  I did a complete re-install and I haven't updated my
autotools.  So, I'm still using the tools that came with the distribution.
It was cut clear back in July with their updates having been cut off
several months earlier.

> I had to autoreconf to get rid of a ton of spurious configure time errors
> on my Mac... oddly, the first autoreconf threw up a ton of unset AC_LANG
> warnings, but when I reran autorecong to log them for later investigation
> - they disappeared.

Weird.  I'll freshen my tools and reconstruct.  Please feel free to use
the mk-libposix script and you'd also use the latest autoreconf.
(Assuming you've got it. :)

> I think I know why pkg-config makes autotools people wince...
>
> <rant>
> I still regret not having noticed pkg-config before it became so pervasive -
> it basically repeats all of the work libtool already did, and then ignores
> a few critically important parts, so that if you use any kind of directory

I submit that it isn't completely too late.  Add a LT_CREATE_PKG_CONFIG
configure macro that spits out a .pc file named after the AC_INIT-named
package.  How hard can that be?  (I am *not* volunteering....)
However, you are certainly right about that PKG_CONFIG_PATH thing.
/etc/sysconfig/pkgconfig would have been very useful.....

> I had to make a few manual changes to get it to build on my Mac:
>
> 1. I removed `--no-undefined' from the libposix_la_LDFLAGS to avoid tripping
>   over _program_name undefined in error_at_line.o and similar in the final
>   link of libposix.

That is done automatically by gnulib-tool.  Should I sed it away?
The Makefile.am file is the most heavily edited:
  1. add version.c version.h mk-libposix-pc-sh.in to EXTRA_DIST
  2. remove all "noinst_LIBRARIES"
  3. replace "noinst_LTL" with "lib_LTL"
  4. tell it to install libposix.pc in the right place and add a rule to make
      it from the configured shell script
  5. augment MOSTLYCLEANFILES and MOSTLYCLEANDIRS
  6. rename output library from libgnu to libposix
  7. change noinst_HEADERS to nobase_nodist_pkginclude_HEADERS
  8. set that to the list of headers

> 2. I removed the hardcoded `-lrt' from pt_chown_LDADD in libposix Makefile.am,
>   since the Mac doesn't have a librt.

Hmmm.  I had to do that to get it to work on Linux.
Some magic will need to be added to figure out whether it needs
adding on the particular build platform.

> 3. While I was there I added `datarootdir="@datarootdir@"' to 
> mk-libposix-pc-sh.in
>   to silence some Automake warnings.

Thank you.  It's in my mk-libposix thing now, too.

> The autogen prerelease tarball doesn't seem to make use of the installed
> libposix though, maybe you put up the wrong one?

Sorry.  Meant to just refer you to the libposix tarball.  autogen is up there
so that Harlan Stenn can play with the new man page templates that
his GSOC student wrote.  The included perl scripts convert program
descriptions into a canonical layout and then produce man pages of
any of several styles.  BSD being different from Solaris being different
from Linux, et al.  There's also a Debian fix for the fact that I moved
all the template stuff into a subdirectory and got over-aggressive in
burning in version numbers.  Anyway, it isn't related.  This stuff is
for autogen 5.12, not 5.11.x.

> I've never liked the gnulib 'non-release' policy, and think that maybe git
> branching at some reasonably stable point from time to time and apply fixes
> to make occasional libposix releases would satisfy my nagging fears that
> the particular non-release of gnulib I've just chosen to base my own package
> release on was not a particularly good or stable one...

That would be nice, but that is why the version number is based on a date
and not incremented by a release.  The intention being that if a developer
can figure out what day a needed feature was added, then his configure
stuff can demand a libposix dated since the next day.

Anyhow, I've got signed paperwork and I'd like to put the script into
build-aux.  I do not know if I've got pushback permissions.

Regards, Bruce