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 (g...@gnu.org)
PGP.sig
Description: This is a digitally signed message part