Auto(conf|make) style questions

Auto(conf|make) style questions

[tomas]

Hi,

it's me again. I have some (kind of) working code and would like
to hear some comments.

My problem seems fairly generic; thus I'm surprised I haven't found
a ready-made one (I won't dismiss the possibility I'm blind. The
Enlightened may help me then ;-)

The Problem:

We're trying to build a library (call it guile-neon) which links to
an existing one (call it guile), and would like to inter-operate
with different versions. If an older version doesn't provide some
function, we'll have to do it ourselves. Kind of what AC_REPLACE_FUNCS
does at the libc level.

This is what I've come up with so far:
(from configure.in)

  +------------------------------------------------------------------------------------------
  | # Grrr. I'd like to use AC_REPLACE_FUNCS here.
  | AC_CACHE_CHECK([whether your Guile has scm_c_string2str() (around version > 1.6.xx)],
  |                [guile_neon_cv_has_string2str],
  |                [guile_neon_save_CFLAGS=$CCFLAGS; CFLAGS="$CCFLAGS `guile-config compile`"
  |                 guile_neon_save_LDFLAGS=$LDFLAGS; LDFLAGS="$LDFLAGS `guile-config link`"
  |                 AC_TRY_LINK([#include <libguile.h>],
  |                             [int len; char *foo=scm_c_string2str(NULL, NULL, &len);],
  |                             [guile_neon_cv_has_string2str=yes],
  |                             [guile_neon_cv_has_string2str=no])
  |                 LDFLAGS=$guile_neon_save_LDFLAGS
  |                 CFLAGS=$guile_neon_save_CFLAGS
  |                ])
  | 
  | if test "$guile_neon_cv_has_string2str" = "no"; then
  |   echo "Including scm_c_string2str.c in object files"
  |   AC_LIBOBJ(scm_c_string2str)
  | fi
  +------------------------------------------------------------------------------------------

And this is in Makefile.am:

  +------------------------------------------------------------------------------------------
  | libguile_neon_neon_la_SOURCES = $(BUILT_SOURCES) neon.c neon.h
  | libguile_neon_neon_la_LDFLAGS = -version-info 0:0 -export-dynamic $(NEON_LIBS)
  | libguile_neon_neon_la_LIBADD = $(LIBOBJS)
  +------------------------------------------------------------------------------------------

Now my questions:

  - Is this the right way to do things?
  - AC_LIBOBJ passes the extra objects through $(LIBOBJS). That means that I can
    only do it globally, not for a specific binary. Is there another way?

Regards
-- tomas

Re: Auto(conf|make) style questions

[Rob Browning]

tomas@fabula.de writes:

>   - AC_LIBOBJ passes the extra objects through $(LIBOBJS). That
>   means that I can only do it globally, not for a specific
>   binary. Is there another way?

Offhand, I don't think so.  Many of the autoconf default behaviors
only act globally.  Though I guess if you know everything that
AC_LIBOBJ affects, you could grab the values before running the test,
grab the values after, diff them, and then see what changed, but I
wouldn't want to do that :>

I ran in to a similar problem with the config.h fixes where I needed
to test stdint.h if it was available for a set of types, and then test
inttypes.h if it was available for some of the same types.  The
problem is that autoconf didn't allow me to avoid caching the results,
so if the types were found in stdint.h, then those results would
shadow any further tests.  To fix this, I had to do something fairly
ugly:

  unset ac_cv_type_int8_t
  unset ac_cv_type_uint8_t
  ...

between the AC_CHECK_TYPES runs.  Though this could be fragile against
autoconf upgrades, having it fail wouldn't be catastrophic, so I'm not
too worried.

Unless you can't, or there's some limitation I'm not thinking of, I
probably still be more likely to use #if guile version testing:

  #if GUILE_MAJOR_VERSION >= ... && GUILE_MINOR_VERSION ...

though if I wanted more specific, per-function testing, I guess I
might test for the features in configure.in and then stick a "#define
GNEON_NEEDS_SCM_C_STRING2STR 1" into a public config header (but not
config.h, unless you don't need the symbol publically).

Alternately, you could centralize the version info in a header, but
still have per-issue defines:

  #if GUILE_MAJOR_VERSION >= ... && GUILE_MINOR_VERSION ...
  # define GNEON_NEEDS_SCM_C_STRING2STR 1
  # define GNEON_HAS_TO_CORRECT_FOR_GUILE_CRUFT_BAR 1
  #endif

etc.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Auto(conf|make) style questions

[Mikael Djurfeldt]

tomas@fabula.de writes:

> The Problem:
>
> We're trying to build a library (call it guile-neon) which links to
> an existing one (call it guile), and would like to inter-operate
> with different versions. If an older version doesn't provide some
> function, we'll have to do it ourselves. Kind of what AC_REPLACE_FUNCS
> does at the libc level.
>
> This is what I've come up with so far:
> (from configure.in)

You might be able to use some ideas from CVS guile-core/examples/compat.

M


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Auto(conf|make) style questions

[Alexandre Duret-Lutz]

>>> "tomas" == tomas  <tomas@fabula.de> writes:

[...]

 >> libguile_neon_neon_la_LIBADD = $(LIBOBJS)

I think you meant $(LTLIBOBJS)

[...]

 tomas> - AC_LIBOBJ passes the extra objects through
 tomas> $(LIBOBJS). That means that I can only do it globally,
 tomas> not for a specific binary.  Is there another way?

Sure... don't use LIBOBJS :)

For instance replace

 if test "$guile_neon_cv_has_string2str" = "no"; then
   echo "Including scm_c_string2str.c in object files"
   AC_LIBOBJ(scm_c_string2str)
 fi

by something like

 if test "$guile_neon_cv_has_string2str" = "no"; then
   echo "Including scm_c_string2str.c in object files"
   NEON_COMPAT="$NEON_COMPAT scm_c_string2str.lo"
 fi
 AC_SUBST([NEON_COMPAT])

and use

 libguile_neon_neon_la_LIBADD = $(NEON_COMPAT)
 EXTRA_libguile_neon_neon_la_SOURCES = scm_c_string2str.c
-- 
Alexandre Duret-Lutz

Re: Auto(conf|make) style questions

[tomas]

On Wed, Mar 19, 2003 at 11:39:12AM -0600, Rob Browning wrote:
> tomas@fabula.de writes:
> 
> >   - AC_LIBOBJ passes the extra objects through $(LIBOBJS). That
> >   means that I can only do it globally, not for a specific
> >   binary. Is there another way?
> 
> Offhand, I don't think so. [...]

Thanks, Rob. Your answera are always very helpful.

> I ran in to a similar problem with the config.h fixes [...]

Yuck. I keep asking myself wyh those things have to be so messy.

> Unless you can't, or there's some limitation I'm not thinking of, I
> probably still be more likely to use #if guile version testing:
> 
>   #if GUILE_MAJOR_VERSION >= ... && GUILE_MINOR_VERSION ...
> 
> though if I wanted more specific, per-function testing, I guess I
> might test for the features in configure.in and then stick a "#define
> GNEON_NEEDS_SCM_C_STRING2STR 1" into a public config header (but not
> config.h, unless you don't need the symbol publically).
> 
> Alternately, you could centralize the version info in a header, but
> still have per-issue defines:
> 
>   #if GUILE_MAJOR_VERSION >= ... && GUILE_MINOR_VERSION ...
>   # define GNEON_NEEDS_SCM_C_STRING2STR 1
>   # define GNEON_HAS_TO_CORRECT_FOR_GUILE_CRUFT_BAR 1
>   #endif

Yup. It's the old ``version test versus feature test'' issue. I'll
prepare another post on that.

Thanks for your suggestions.

Regards
-- tomas

Re: Auto(conf|make) style questions

[tomas]

On Wed, Mar 19, 2003 at 08:26:26PM +0100, Alexandre Duret-Lutz wrote:
> >>> "tomas" == tomas  <tomas@fabula.de> writes:
> 
> [...]
> 
>  >> libguile_neon_neon_la_LIBADD = $(LIBOBJS)
> 
> I think you meant $(LTLIBOBJS)
> 
> [...]
> 
>  tomas> - AC_LIBOBJ passes the extra objects through
>  tomas> $(LIBOBJS). That means that I can only do it globally,
>  tomas> not for a specific binary.  Is there another way?
> 
> Sure... don't use LIBOBJS :)
> 
> For instance replace
> 
>  if test "$guile_neon_cv_has_string2str" = "no"; then
>    echo "Including scm_c_string2str.c in object files"
>    AC_LIBOBJ(scm_c_string2str)
>  fi
> 
> by something like
> 
>  if test "$guile_neon_cv_has_string2str" = "no"; then
>    echo "Including scm_c_string2str.c in object files"
>    NEON_COMPAT="$NEON_COMPAT scm_c_string2str.lo"
                                               ^^^^       EEEK! ;-)

>  fi
>  AC_SUBST([NEON_COMPAT])
> 
> and use
> 
>  libguile_neon_neon_la_LIBADD = $(NEON_COMPAT)
>  EXTRA_libguile_neon_neon_la_SOURCES = scm_c_string2str.c

If I understand the configury documentation correctly -- isn't using
explicit dynamic object endings a ``Don't Do That?'' and exactly what
$(LIBOBJS) or $(LTLIBOBJS) is supposed to handle for you? For .lo is
platform specific...

(and no, if I understand... correctly above is no useless rethoric.
I have too often the feeling that those docs are beyond me, really).

But yes, thank you for your idea.

Regards
-- tomas


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Auto(conf|make) style questions

[tomas]

On Wed, Mar 19, 2003 at 06:57:26PM +0100, Andreas Rottmann wrote:
> tomas@fabula.de writes:
> 
> [not CCing autoconf, since this is not really AC-specific]
> 
> > Hi,

[...]

Thanks, Andreas, Rob, Mikael and Alexandre for your comments.

> It's certainly possible to do a feature test for each non-portable
> function, but there is another way: Test for the guile version and use
> a portability header + source file [...]

See below.

> BTW: It might be useful to have some coordinated work here and have a
> tiny 'guile compatibilty project'.

Definitely, and this was part of the purpose of my whining ;-)

I'm having a look at your approach in Serveez and at Mikael's proposal
in CVS Guile guile-core/examples/compat. Yes, I think this could ease
transitions quite a bit, and allow people to `code towards future
interfaces' instead of sticking to old ones for the sake of compatibility.

As far as I see, we have several choices:

Version test versus feature test:

Each approach has its merits and disadvantages. As far as I understand,
configury has a strong leaning towards feature test; i guess that it
just scales better to many/big libs. I had a bias towards feature tests
myself, but after reading Rob's and Andreas' posts I'm not so sure
anymore (I have a high opinion of your taste in such things).

Note that Mikael's proposal goes the ``feature test'' way.

Version test:

  pros:
    - test is simpler: you just check for a version and take in
      an appropriate compat header/lib depending on the result.
    - test catches better `semantic' changes: the name/interface of a
      function doesn't change, but some subtle semantics in the
      implementation.

  cons:
    - it doesn't scale very well across many versions of a lib
    - it is a more brittle ``all-or-nothing'' approach (this may
      be seen as a restatement of the above).

For feature test, just reverse/negate pros and cons.

I'm trying to come up with something which can be used as a model for
a compatibility project, as Andreas proposes. I'd love to have something
more general, but a 1.6/1.7 transition help thing would be already
great.

What do you think?

Regards
-- tomas


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Auto(conf|make) style questions

[Alexandre Duret-Lutz]

>>> "tomas" == tomas  <tomas@fabula.de> writes:

[...]

 >> NEON_COMPAT="$NEON_COMPAT scm_c_string2str.lo"
 tomas>                                       ^^^^       EEEK! ;-)

[...]

 tomas> If I understand the configury documentation correctly -- isn't using
 tomas> explicit dynamic object endings a ``Don't Do That?'' and exactly what
 tomas> $(LIBOBJS) or $(LTLIBOBJS) is supposed to handle for you? For .lo is
 tomas> platform specific...

No.  `.lo' is portable.  What wasn't portable in the way people used
to define LTLIBOBJS from LIBOBJS was the hardcoding of `.o'.
-- 
Alexandre Duret-Lutz

Re: Auto(conf|make) style questions

[tomas]

On Fri, Mar 21, 2003 at 09:17:17PM +0100, Alexandre Duret-Lutz wrote:
> >>> "tomas" == tomas  <tomas@fabula.de> writes:
> 
> [...]
> 
>  >> NEON_COMPAT="$NEON_COMPAT scm_c_string2str.lo"
>  tomas>                                       ^^^^       EEEK! ;-)
> 
> [...]
> 
>  tomas> If I understand the configury documentation correctly -- isn't using
>  tomas> explicit dynamic object endings a ``Don't Do That?'' and exactly what
>  tomas> $(LIBOBJS) or $(LTLIBOBJS) is supposed to handle for you? For .lo is
>  tomas> platform specific...
> 
> No.  `.lo' is portable.  What wasn't portable in the way people used
> to define LTLIBOBJS from LIBOBJS was the hardcoding of `.o'.

Ah, I stand corrected. Thanks a lot for the clarification. Then your suggestion
makes indeed a lot of sense.

Regards
-- tomas

Re: Auto(conf|make) style questions

[Neil Jerram]

>>>>> "tomas" == tomas  <tomas@fabula.de> writes:

    tomas> I'm trying to come up with something which can be used as a
    tomas> model for a compatibility project, as Andreas proposes. I'd
    tomas> love to have something more general, but a 1.6/1.7
    tomas> transition help thing would be already great.

    tomas> What do you think?

I think this is an excellent idea.  Possibly a good way to pin down
the options is to start with a test plan:
- select a group of Guile-using applications and libraries that you
  plan to test with
- start trying to build them against different Guile versions
- see what the issues are.

Regards,
        Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel