After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 108695 - 'autoheader' and 'autoreconf' fails
'autoheader' and 'autoreconf' fails
Status: RESOLVED FIXED
Product: gtkmm
Classification: Bindings
Component: build
2.2
Other other
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2003-03-18 19:21 UTC by Enrico Scholz
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix for issues with autoconf-2.57 and autoreconf (2.97 KB, patch)
2003-03-18 19:22 UTC, Enrico Scholz
none Details | Review

Description Enrico Scholz 2003-03-18 19:21:56 UTC
autoconf's 'autoheader' fails because descriptions are missing in several
AC_DEFINE statements. There should be an 'ACLOCAL_AMFLAGS' variable in the
toplevel-Makefile.am; else 'autoreconf' is not working.


The attached patch fixes these issues.
Comment 1 Enrico Scholz 2003-03-18 19:22:40 UTC
Created attachment 15103 [details] [review]
Fix for issues with autoconf-2.57 and autoreconf
Comment 2 Murray Cumming 2003-03-19 15:43:37 UTC
1. I wonder why this works with our autogen.sh.
2. Doesn't this normally produce warnings instead of errors?
3. These changes look good. The patch should be committed to 
both "branches", IF our autogen.sh works with if. Thanks.

Comment 3 Enrico Scholz 2003-03-19 21:50:43 UTC
1. It works with autogen.sh because 'autoheader' is commented out
   there ;)
2. It is an error:
   | $ autoheader
   | autoheader: missing template: GTKMM_DEBUG_REFCOUNTING
   | ...
   | $ echo $?
   | 1
Comment 4 Murray Cumming 2003-03-20 08:14:05 UTC
Maybe we don't need to use autoheader.

I said :
"
3. These changes look good. The patch should be committed to 
both "branches", IF our autogen.sh works with if. Thanks.
"

So does our autogen.sh continue to work with these changes?
Comment 5 Enrico Scholz 2003-03-21 05:13:02 UTC
I do not see problems with autogen.sh; it runs without failures and
'make' succeeds also.

My changes are affecting 'autoheader' and 'autoreconf' only.
Comment 6 Murray Cumming 2003-03-21 10:12:03 UTC
Great. This should be applied to both branches, and glibmm too probably.
Comment 7 Murray Cumming 2003-03-22 21:24:12 UTC
Applied to gtkmm 2.2, glibmm 2.4 and gtkmm 2.4.

By the way, why do you want to use autoheader. What does it do that
our autogen.sh does not? In general I think that autoreconf does not
work with GNOME projects, because they do extra stuff such as intltoolize.
Comment 8 Enrico Scholz 2003-03-24 21:12:10 UTC
The main purpose of 'autoheader' is the documentation of the
#defines at *one* place. Without 'autoheader' you will have to
change two files (configure.in/*.m4 and acconfig.h) when
modifying/adding a macroname.

'autogen.sh' tries to do the same like 'autoreconf' but has the
following flaws:

- There exists only one 'autoreconf' but a lot of 'autogen.sh'
  scripts with diffent options and/or semantics (e.g. some are
  calling ./configure, other ones do not).  When employing or
  packaging new software it requires additional work to figure
  out what 'autogen.sh' is doing.
- 'autoreconf' has more options than autogen.sh; e.g. 'autoreconf
  -i -f' can be used to recover from a broken build- environment.
  With 'autogen.sh' some tasks must be done manually.
- 'autoreconf' supports the AUTO* environment variables selecting
  the used autotool version. Most 'autogen.sh' scripts are using
  static command names enforcing dirty tricks like copying/linking
  the tools to a certain place and manipulating the PATH.
- 'autoreconf' is written and maintained by the authors of the
  auto* tools.  I have seen a lot of 'autogen.sh' which are
  erroneously (e.g. '==' instead of '=' in tests, special
  assumptions about the development environment, tools are
  called in the wrong order).

Therefore, I do not like the typical 'autogen.sh'. Additional tasks
like calling 'intltoolize' do not conflict with 'autoreconf', e.g. you
can still execute 'autoreconf && intltoolize'.
Comment 9 Murray Cumming 2003-03-25 14:20:08 UTC
> The main purpose of 'autoheader' is the documentation of the
> #defines at *one* place. Without 'autoheader' you will have to
> change two files (configure.in/*.m4 and acconfig.h)

But we have no acconfig.h

> 'autogen.sh' tries to do the same like 'autoreconf' but has the
> following flaws:
[snip]
> Additional tasks
> like calling 'intltoolize' do not conflict with 'autoreconf', e.g. 
> you can still execute 'autoreconf && intltoolize'.

I'm all for using autoreconf if it works.

But I suggest that you try writing an autogen.sh for gnome-hello, that
has something like
autoreconf
intltoolize inside.

I think it will be more difficult than you think because the
intltoolize (and/or maybe glib-gettextize) needs to be somewhere
inside the autoreconf process.

gtkmm isn't a good test of the theory because we don't have translated
strings.


Comment 10 Enrico Scholz 2003-03-25 15:15:22 UTC
> But I suggest that you try writing an autogen.sh for gnome-hello, that
> has something like autoreconf intltoolize inside.

When fixing two issues (replacing AM_GLIB_GNU_GETTEXT with
AM_GNU_GETTEXT([external]) and copying /usr/share/gettext/po/Makevars
manually into po/) it is easy to generating such an autogen.sh:

| autoreconf -i -f && intltoolize --force
Comment 11 Murray Cumming 2003-03-25 15:53:03 UTC
This really is _not_ the place for this discussion, but I happen to be
maintating gnome-hello now, so if you can send me a patch then I'll
look at it and take it further.