Hi Bruce,
On 11 Oct 2010, at 12:06, Bruce Korb wrote:
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
Hi Bruce,
On 9 Oct 2010, at 22:40, Bruce Korb wrote:
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
Hi Gary,
On Mon, Oct 11, 2010 at 12:31 AM, Gary V. Vaughan wrote:
It is the .pc files that are the problem actually.
Yes. I understand. It is a nuisance to find them on a system.
libtool already contains most of the information that pkg-config wants,
Yep. And rather than what would likely
Hi Bruce,
On 11 Oct 2010, at 22:10, Bruce Korb wrote:
On Mon, Oct 11, 2010 at 12:31 AM, Gary V. Vaughan wrote:
libtool already contains most of the information that pkg-config wants,
Yep. And rather than what would likely be a futile fight to
migrate from ``pkg-config --cflags libname'' to
[adding bug-autoconf]
On 10/10/2010 11:02 PM, Gary V. Vaughan wrote:
Hi Bruce,
On 10 Oct 2010, at 22:26, Bruce Korb wrote:
The common way to get rid of these warnings is to insert an invocation of
gl_USE_SYSTEM_EXTENSIONS at the appropriate place in configure.ac.
Could you explicitly define
On 10/10/2010 08:19 PM, Gary V. Vaughan wrote:
The common way to get rid of these warnings is to insert an invocation of
gl_USE_SYSTEM_EXTENSIONS at the appropriate place in configure.ac.
Seems like a kludge to me. Either the AC_{RUN,COMPILE}_IFELSE using modules
should
Hello Gary,
* Gary V. Vaughan wrote on Mon, Oct 11, 2010 at 09:31:55AM CEST:
On 9 Oct 2010, at 22:40, Bruce Korb wrote:
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
Hi Bruce, Bruno,
On 10 Oct 2010, at 03:25, Bruce Korb wrote:
May I push the script as it can have no effect without someone
explicitly running it?
Attached is another copy, different from the last only in that datarootdir was
added to the generate-libtool.pc-script.
I think your script is
On 10 Oct 2010, at 16:14, Gary V. Vaughan wrote:
2 bugs need fixing for this to work as intended:
D'oh. Make that 4. I kept editing the list, but forgot to update the sentence.
3. missing AM_CONDITIONAL declarations
--
I suppose the following definitions
Hi Gary,
I think your script is *much* more complicated than it needs to be. Far
easier to let the existing gnulib machinery populate an installable
libposix project, surely? See below for my alternative two line script =)O|
I agree that while a single-file bash script was a good way for
Hi Gary,
On 10/10/10 02:14, Gary V. Vaughan wrote:
I think your script is *much* more complicated than it needs to be.
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,
Hi Bruno,
On 10/10/10 07:35, Bruno Haible wrote:
Since creating a separate git repository is a lot of administrative work,
I would suggest that you (Bruce + Gary) create a subdirectory in gnulib,
Since it is completely tied to gnulib, it is also appropriate.
Also, I tried. Can you please fix
Hi Bruno,
Another point:
On 10/10/10 07:35, Bruno Haible wrote:
I would suggest that you ... create a subdirectory in gnulib,
called 'libposix', with files such as
configure.ac
Makefile.am
version.in.h
version.c
README
libposix.m4
bootstrap
and then use gnulib-tool
Bruce Korb wrote:
The common way to get rid of these warnings is to insert an invocation of
gl_USE_SYSTEM_EXTENSIONS at the appropriate place in configure.ac.
Could you explicitly define appropriate place in the sample above? :)
Appropriate place means a line; which line, you determine by
Bruce Korb wrote:
Whether you use one file or multiple, it is still useful to
*not* construct the thing where your template sources live.
Since the AC_INIT macro clearly must be auto-edited, you
must construe these files to be templates ...
That means a configure.ac.in? Nah, that's overkill.
On 10/10/10 09:11, Bruno Haible wrote:
Bruce Korb wrote:
Whether you use one file or multiple, it is still useful to
*not* construct the thing where your template sources live.
Since the AC_INIT macro clearly must be auto-edited, you
must construe these files to be templates ...
That means
Hi Bruno,
Bruno wrote:
The common way to get rid of these warnings is to insert an invocation
of
gl_USE_SYSTEM_EXTENSIONS at the appropriate place in configure.ac.
Could you explicitly define appropriate place in the sample above? :)
Appropriate place means a line; which line, you
[adding bug-autoconf for AC_COMPILE_IFELSE comment]
On 10 Oct 2010, at 21:35, Bruno Haible wrote:
Hi Gary,
Hallo Bruno,
Thanks for the quick feedback.
I think your script is *much* more complicated than it needs to be. Far
easier to let the existing gnulib machinery populate an installable
On 10 Oct 2010, at 22:00, Bruce Korb wrote:
Hi Gary,
Hey Bruce!
On 10/10/10 02:14, Gary V. Vaughan wrote:
I think your script is *much* more complicated than it needs to be.
Of course it is. To properly understand 150+ lines of usage text
one needs to read the source and understand the
Hi Bruno,
On 11 Oct 2010, at 09:19, Gary V. Vaughan wrote:
It occurs to me also, that when another gnulib using project (that relies on
non-libposix modules) wants to minimise it's configury by requiring
libposix,
gnulib-tool will need an --avoid-posix option or similar so as not to end up
Hi Bruno,
On 11 Oct 2010, at 09:19, Gary V. Vaughan wrote:
- You want to install the library, which can be done by specifying to
gnulib-tool a module (via --local-dir) which contains
lib_LTLIBRARIES = libposix.la
When gnulib-tool sees this declaration in a module, it will not emit
Hi Bruce,
On 10 Oct 2010, at 22:26, Bruce Korb wrote:
The common way to get rid of these warnings is to insert an invocation of
gl_USE_SYSTEM_EXTENSIONS at the appropriate place in configure.ac.
Could you explicitly define appropriate place in the sample above? :)
I took a guess, based upon
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
Hello Gary,
* Gary V. Vaughan wrote on Sat, Oct 09, 2010 at 05:48:04AM CEST:
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
On 9 Oct 2010, at 15:13, Ralf Wildenhues wrote:
Hello Gary,
Hallo Ralf,
* Gary V. Vaughan wrote on Sat, Oct 09, 2010 at 05:48:04AM CEST:
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
Hi Gary,
On Fri, Oct 8, 2010 at 8:48 PM, Gary V. Vaughan g...@gnu.org 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
Hi Gary,
* Gary V. Vaughan wrote on Sat, Oct 09, 2010 at 02:45:57PM CEST:
On 9 Oct 2010, at 15:13, Ralf Wildenhues wrote:
* Gary V. Vaughan wrote on Sat, Oct 09, 2010 at 05:48:04AM CEST:
...ah, that's because autoreconf is still running aclocal before
libtoolize,
autoreconf runs
Gary V. Vaughan wrote:
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
This already happens for a year now. We _are_ making
On Sat, Oct 9, 2010 at 12:12 PM, Bruno Haible br...@clisp.org wrote:
Gary V. Vaughan wrote:
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
Hi Bruno,
On Oct 10, 2010, at 2:12 AM, Bruno Haible br...@clisp.org wrote:
Gary V. Vaughan wrote:
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
Hey Gary,
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
Hey Gary,
(re-send -- I didn't see the first one show up on bug-gnulib list.)
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
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
Yes, and actually, that bugs me quite a lot. While gnulib is still finding
its feet, that's still acceptable, but at some point (the core interfaces of)
gnulib really ought to settle down. And I've moaned on and off that it
really would be very nice (for the sake of being able to rebuild
Hi Eric,
Thanks for the feedback.
On 27 Sep 2008, at 01:04, Eric Blake wrote:
Gary V. Vaughan gary at gnu.org writes:
I have an (undoubtedly caffeine induced) idea... why not enhance
gnulib to provide a shim that sits between the system libraries and
client code that wants to use it without
Gary V. Vaughan wrote:
I think some folks won't buy into it because they don't want another
dependency
for their projects. (I think that was the main objection to my
proposal for that long-ago contest.
Really? I thought the main objection was that writing the glue layer would
take a
I have an (undoubtedly caffeine induced) idea... why not enhance
gnulib to provide a shim that sits between the system libraries and
client code that wants to use it without shipping (another copy) of
the particular parts it depends upon?
If we add a
On Fri, Sep 26, 2008 at 9:25 AM, Gary V. Vaughan [EMAIL PROTECTED] wrote:
I have an (undoubtedly caffeine induced) idea... why not enhance gnulib to
provide a shim that sits between the system libraries and client code that
wants to use it without shipping (another copy) of the particular parts
Gary V. Vaughan gary at gnu.org writes:
I have an (undoubtedly caffeine induced) idea... why not enhance
gnulib to provide a shim that sits between the system libraries and
client code that wants to use it without shipping (another copy) of
the particular parts it depends upon?
I am
Hi Gary,
why not enhance
gnulib to provide a shim that sits between the system libraries and
client code that wants to use it without shipping (another copy) of
the particular parts it depends upon?
It does not take a lot of steps to do that:
1) $ gnulib-tool --create-testdir
40 matches
Mail list logo
