On 4/24/06, Bruno Haible <[EMAIL PROTECTED]> wrote:
> Keywords with nested groups of C-like compound statements as values:
> Other groups of keyword / value pairs:
> Scripting language with at least conditional statements:
> XML:
> List of numbers:
> Other custom text format:
Don't know. Not likely.
> Binary format:
Certainly not.
> It appears that different programs have wildly different needs in this area...
> Of course, it involves a new Autoconf macro to test whether the library
> is available. And of course again, I don't want that macro to live in
> GNU Hello, since the goal is not Hello functionality, it's to be an
> example. So I want it to be in a common place. Which I guess is
> gnulib.
Why not have libopts itself provide and install the autoconf macro that
recognizes it?
> +AC_DEFUN([ag_FIND_LIBOPTS],
> + [if test "X${ac_cv_header_autoopts_options_h}" == Xno
> + then
> + :
> + else
> + f=`autoopts-config cflags` 2>/dev/null
> + test X"${f}" = X && f=`libopts-config cflags` 2>/dev/null
These xyz-config scripts have two flaws by design:
1) They don't support using the library with a different compiler than the
one that built it. Indeed, the CFLAGS that are supported by one compiler
are not supported by other compilers. Likewise for the "-Wl,-R/usr/lib"
option reported as being present in `autoopts-config ldflags`: it does
not work when the compiler is not gcc.
2) They expect to be found in PATH. I.e. in order to use packages installed
in /foo/bar, it is no longer sufficient to set
CPPFLAGS=-I/foo/bar/include
LDFLAGS=-L/foo/bar/lib
but it's also needed to set
PATH=/foo/bar/bin:$PATH
Better use the AC_LIB_LINKFLAGS or AC_LIB_HAVE_LINKFLAGS macro from gnulib.
It doesn't have these flaws.
Karl Berry wrote on 2006-02-13:
> Bruce Korb implemented a library for straightforward config file
> parsing (among other things). We thought it would make sense to use it
> for GNU Hello, as an example of how it can be done.
How come so few programs use this libopts? Let me look at the syntax of
the various .??* files in my home directory.
I do not think it is due to lack of support for any given format (see below).
More likely, it is little known and once a project has a .ini file parser, why
bother with the trouble to replace it? The idea I think is to make it known that
there is a library around that will enable you to pull configuration information
from a config file without having to write your own config file parser or use
an XML library. (Most folks hate writing XML anyway.)
> Plain list of keyword / value pairs:
check. It is supported.
X11 resources syntax:
Yep
List of keyword / value pairs, with groups and parametrized keywords:
Also
Nested groups of C-like compound statements with braces and semicolons:
Nope. :(
> Keywords with nested groups of C-like compound statements as values:
XML is accepted. That is compound.
> Windows ini syntax ([Group]s of Keyword=Value statements):
Yep.
> Other groups of keyword / value pairs:
No idea. If the syntax can be expressed as:
value-name white-space value
or
value-name optional-space intro-character optional-space value
then the data can be sucked up and delivered in a digested form to the program.
> Scripting language with at least conditional statements:
Clearly not.
> XML:
Yep.
> List of numbers:
I doubt it could be easily supported.
> Single identifier:
No sweat.
No sweat.
> Other custom text format:
Don't know. Not likely.
> Binary format:
Certainly not.
> It appears that different programs have wildly different needs in this area...
I was not claiming that it would solve all .ini file problems for all programs.
Simply that programs with modest needs for name/value pairs could use
the library. It would make handling the data somewhat easier. The real
ultimate benefit is to be able to configure the run of a program with command
line options, environment variables and .ini/.rc files equivalently. But, of
course, that requires more than just libopts.
> Of course, it involves a new Autoconf macro to test whether the library
> is available. And of course again, I don't want that macro to live in
> GNU Hello, since the goal is not Hello functionality, it's to be an
> example. So I want it to be in a common place. Which I guess is
> gnulib.
Why not have libopts itself provide and install the autoconf macro that
recognizes it?
> +AC_DEFUN([ag_FIND_LIBOPTS],
> + [if test "X${ac_cv_header_autoopts_options_h}" == Xno
> + then
> + :
> + else
> + f=`autoopts-config cflags` 2>/dev/null
> + test X"${f}" = X && f=`libopts-config cflags` 2>/dev/null
These xyz-config scripts have two flaws by design:
1) They don't support using the library with a different compiler than the
one that built it. Indeed, the CFLAGS that are supported by one compiler
are not supported by other compilers. Likewise for the "-Wl,-R/usr/lib"
option reported as being present in `autoopts-config ldflags`: it does
not work when the compiler is not gcc.
``when the compiler is different from the one used to build autoopts''.
Completely true. I sure haven't a clue what to do about it. Other than
put the burden on the guy who wants to use the different compiler.
(You can specify your own linkage options, of course, but they won't
be gotten so easily from the xxx-config script.)
2) They expect to be found in PATH. I.e. in order to use packages installed
in /foo/bar, it is no longer sufficient to set
CPPFLAGS=-I/foo/bar/include
LDFLAGS=-L/foo/bar/lib
but it's also needed to set
PATH=/foo/bar/bin:$PATH
Better use the AC_LIB_LINKFLAGS or AC_LIB_HAVE_LINKFLAGS macro from gnulib.
It doesn't have these flaws.
I'll happily use or adapt anything anybody suggests. Thank you for the suggestion!
Regards, Bruce.
