Hello Paul,

* Paul Eggert wrote on Thu, Jun 22, 2006 at 01:36:20AM CEST:
> Ralf Wildenhues <[EMAIL PROTECTED]> writes:
> 
> > Next, for the transition
> > time, it's extremely helpful if the package bootstraps unchanged with
> > both 2.59 and 2.60.  So far, I think all datarootdir induced changes can
> > be written in a backwards compatible way (so they work with 2.59).
> 
> This needs documentation, surely.  Perhaps even a separate page in the
> manual.  The issue is confusing, and this stuff needs to be explained
> clearly.

That is what I feared.  ;-)

> > So how about let's make the silencing also backward compatible, to keep
> > the smooth upgrade path?
> 
> Sorry, I don't follow.  The proposed AC_DATAROOTDIR_CHECKED macro
> cannot be used in configure.ac files intended to be portable to 2.59.

Yes, it can.  The point is that users don't add
  AC_DATAROOTDIR_CHECKED

but instead they define the macro:
  AC_DEFUN([AC_DATAROOTDIR_CHECKED])

which will simply be ignored by older Autoconf versions.

> It sounds like your scenario is more like this -- am I right?
> 
> * The source package works with 2.59.
> 
> * With 2.60 there are a lot of annoying warnings.
> 
> * Maintainer manually reviews each warning, and fixes the underlying
>   package so that it works under either 2.59 or 2.60.

Right.

>   (An example
>   or two?  How can the package use datarootdir under 2.59 when 2.59
>   doesn't define it?)

Well, the usual solution is to add an initialization
  [EMAIL PROTECTED]@

somewhere.

> * Unfortunately, even if the underlying package is fixed, autoconf 2.60
>   sometimes issues false alarms

Right.

>   (what's an example of this?).

A hand-written Makefile.in that is, say, GNU make specific and uses its
`include' mechanism; the definition of datarootdir is done in an
included snippet.

>   So there's
>   a way to shut off all alarms.  (There isn't a way to shut off the alarm
>   selectively, just for the false alarms that have been manually checked,
>   because ....?)

Right.

I guess I'll look into writing...

Cheers,
Ralf


Reply via email to