Re: KDE 3.5.5 autoconf errors

[Ralf Wildenhues]

* Matthew Woehlke wrote on Thu, Jan 11, 2007 at 01:01:09AM CET:
> Ralf Wildenhues wrote:
> >>I don't have autoconf > 2.59 on that box, but I am forwarding this to 
> >>> kde-devel to see if anyone else can help (and to let them know about 
> >>the > problem). Any autoconf folks that want to look could download any 
> >>KDE > 3.5.5 package to see an example of this problem (at least I guess 
> >>any > package will do, I am building artwork ATM).
> >
> >But we don't necessarily have your exact system to test on, so if you do
> >not post the corresponding bits of config.log that show the errors that
> >belong to these warnings, then helping you is so much more work.
> 
> I wasn't talking about the "real" errors, I was talking about the 
> appearance of "AC_PACKAGE_NAME" in the errors (and configure, really). 

So the first issue in my list.

> Therefore I think what you really want is the computer of the person 
> that rolled the packages. :-)

Yes.

> Actually, looking in e.g. 
> http://websvn.kde.org/branches/KDE/3.5/kdelibs/configure.in.in?rev=526641&view=markup
>  
> I see "AC_INIT(acinclude.m4)". I'm not sure what this means...?

That's the old-style AC_INIT:
<http://www.gnu.org/software/autoconf/manual/html_node/Obsolete-Macros.html#index-AC_005fINIT-1477>
as opposed to the new-style AC_INIT:
<http://www.gnu.org/software/autoconf/manual/html_node/Initializing-configure.html#index-AC_005fINIT-22>
(where "new" means: supported by all Autoconf versions released in the
last 5 years).

> I assume/hope it is safe to freshly unpack a package and (re-)run 
> 'autoconf' and see what is generated?

Barring any incompatibilies, yes.  (And yes, I'd appreciate reporting
any incompatibilies not mentioned in autoconf/NEWS.)

> Ok, so autoconf-2.60 on my computer generates the same bad-ness from the 
> same input. Would this be something about "AC_INIT(acinclude.m4)"? I 
> looked at that file, but I have no clue what it is doing, so I don't 
> know what it might be missing to set the bug report address.

Hmm.  I tried to reproduce that, but failed.  With 2.60 and newer, I get
something like this only:
| checking foobar.h usability... no
| checking foobar.h presence... yes
| configure: WARNING: foobar.h: present but cannot be compiled
| configure: WARNING: foobar.h:     check for missing prerequisite headers?
| configure: WARNING: foobar.h: see the Autoconf documentation
| configure: WARNING: foobar.h:     section "Present But Cannot Be Compiled"
| configure: WARNING: foobar.h: proceeding with the preprocessor's result
| configure: WARNING: foobar.h: in the future, the compiler will take precedence

That's worse than providing an address, but when we have none to
provide, at least it shouldn't be confusing for the user.  So if you
happen to get an output containing the string AC_PACKAGE_NAME, then
please post a small example to reproduce it.  Thanks.

Cheers,
Ralf