[Top][All Lists]

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

Re: Spurious datarootdir warnings in Wine configure

From: Ralf Wildenhues
Subject: Re: Spurious datarootdir warnings in Wine configure
Date: Thu, 22 Jun 2006 06:51:27 +0200
User-agent: Mutt/1.5.11+cvs20060403

Hello Paul,

* Paul Eggert wrote on Thu, Jun 22, 2006 at 01:36:20AM CEST:
> Ralf Wildenhues <address@hidden> 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

but instead they define the macro:

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.


>   (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


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


>   (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 ....?)


I guess I'll look into writing...


reply via email to

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