[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-gnulib] libopts and gnulib?

From: Bruno Haible
Subject: Re: [bug-gnulib] libopts and gnulib?
Date: Mon, 24 Apr 2006 13:54:24 +0200
User-agent: KMail/1.5

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.

  Plain list of keyword / value pairs:

  X11 resources syntax:

  List of keyword / value pairs, with groups and parametrized keywords:

  Nested groups of C-like compound statements with braces and semicolons:

  Keywords with nested groups of C-like compound statements as values:

  Parametrized keywords with nested groups of C-like compound statements as

  Windows ini syntax ([Group]s of Keyword=Value statements):

  Other groups of keyword / value pairs:

  Scripting language with at least conditional statements:


  List of numbers:

  Single identifier:

  Other custom text format:

  Binary format:

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?

> +    [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
   but it's also needed to set

Better use the AC_LIB_LINKFLAGS or AC_LIB_HAVE_LINKFLAGS macro from gnulib.
It doesn't have these flaws.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]