Re: installable gnulib library

[Gary V. Vaughan]

On 9 Oct 2010, at 04:56, Bruce Korb wrote:
> Hey Gary,

Howdy Bruce,

> (re-send -- I didn't see the first one show up on bug-gnulib list.)

Me neither.

> On 09/26/08 20:34, Gary V. Vaughan wrote:
>>> Long ago, far away and years ago, that is *precisely* the point I was
>>> making. (Remember the autotool bake-off contest?)
>> 
>> I remember it well.  Code Sourcery.
> 
>> The thing that struck me a few days ago was that gnulib actually provides
>> all the code that such a shim would need, only it has to be copied
>> piece-meal into the packages that want to take advantage of it as it stands.
> 
>> Outside of the autotool and GNU communities, the vast majority of people I
>> encounter strongly dislike the difficulty of using autotools in client
> 
> I feel a strong kindred spirit with that "vast majority". :)
> 
>> Wouldn't it be great if we only
>> had to run that stuff *once* (when installing gnulib) and every other
>> command-line package that paid attention could remove all of their
>> autotools glue?
> 
> 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?

>> And no one is telling me I'm an idiot yet... looks like a green light to
>> me :D
> 
> I got tepid support but nobody's saying, "works for me" yet either.
> Have you played with it?

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.

> Attached is a script to do the job.  The resulting project can be found
> here:  http://autogen.sourceforge.net/data/

Bootstrapped with Autoconf 2.59?!? ;)

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.

...ah, that's because autoreconf is still running aclocal before libtoolize,
Wow!, I thought that had been fixed a long time ago.  It kinda-sorta works
because the libtool macros are m4_included from the generated aclocal.m4,
and libtoolize overwrites the out-of-date libtool macro files before
autoconf picks them up.  Oh well... aclocal is going away eventually anyway.

> A little more feedback before spending too much time polishing would be really
> nice.  Especially for how best to publicize the dependencies (having noted
> a bit of resistance to pkg-config) and the autoconf macro.

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
tree to separate parallel installation of multiple package versions, you
have to give pkg-config the entire dependency tree of directories for even
indirectly dependent libraries every time you link.  pkg-config was mis-
conceived and mis-implemented, when a few enhancements to libtool would
have give the gnome developers everything they needed, without having to
waste time on a new tool, or force users to set PKG_CONFIG_PATH to an
insanely (and unneccesarily) long list of directories that is currently
required.  I wish I had been prescient enough to nip it in the bud before
it caused me and anyone else who does package management for a living so
much pain.
</rant>

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.
2. I removed the hardcoded `-lrt' from pt_chown_LDADD in libposix Makefile.am,
   since the Mac doesn't have a librt.
3. While I was there I added `datarootdir="@datarootdir@"' to 
mk-libposix-pc-sh.in
   to silence some Automake warnings.

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

> Ultimately, I think the script belongs in gnulib/build-aux, though it can
> be run from anywhere as long as "gnulib-tool" is in the path.

Sounds reasonable to me.

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

Cheers,
-- 
Gary V. Vaughan (address@hidden)

PGP.sig
Description: This is a digitally signed message part