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 581276 - libpanelappletmm build failure
libpanelappletmm build failure
Status: RESOLVED FIXED
Product: gnomemm
Classification: Deprecated
Component: libpanelappletmm
2.22
Other All
: Low minor
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2009-05-04 08:54 UTC by Priit Laes (IRC: plaes)
Modified: 2009-05-17 12:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
fix-generated-headers-issue.patch (945 bytes, patch)
2009-05-07 13:56 UTC, Priit Laes (IRC: plaes)
rejected Details | Review

Description Priit Laes (IRC: plaes) 2009-05-04 08:54:04 UTC
I have trouble building libpanelappletmm on Gentoo:

[snip]
...
Making all in libpanelappletmm
make[3]: Entering directory `/home/plaes/code/libpanelappletmm/libpanelapplet/libpanelappletmm'
Making all in private
make[4]: Entering directory `/home/plaes/code/libpanelappletmm/libpanelapplet/libpanelappletmm/private'
make[4]: *** No rule to make target `enums_p.h', needed by `all-am'.  Stop.
make[4]: Leaving directory `/home/plaes/code/libpanelappletmm/libpanelapplet/libpanelappletmm/private'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/home/plaes/code/libpanelappletmm/libpanelapplet/libpanelappletmm'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/plaes/code/libpanelappletmm/libpanelapplet'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/plaes/code/libpanelappletmm/libpanelapplet'
make: *** [all-recursive] Error 1
[/snip]


automake (GNU automake) 1.10.2
autoconf (GNU Autoconf) 2.63
ltmain.sh (GNU libtool) 2.2.6
GNU Make 3.81

As the autofoo stuff that's going on behind the scenes is a bit hard to understand, I decided to file a bug...
Comment 1 Murray Cumming 2009-05-06 20:45:04 UTC
We see these errors every now and then, probably due to strange combinations of autotools versions. Particularly on gentoo, I recommend that you build from a tarball instead of from git.
Comment 2 David King 2009-05-07 08:58:54 UTC
(In reply to comment #1)
> We see these errors every now and then, probably due to strange combinations of
> autotools versions. Particularly on gentoo, I recommend that you build from a
> tarball instead of from git.

Murray, I get this same error on Ubuntu Jaunty also. The above version (although unspecified) is the tarball release of 2.22.0, not latest Git, although I get the same problem with latest Git.
Comment 3 Murray Cumming 2009-05-07 09:28:40 UTC
David, is that in jhbuild?

You might have some luck trying to make the autogen.sh more like the autogen.sh files in more commonly used modules such as libgdamm.
Comment 4 Daniel Elstner 2009-05-07 11:48:32 UTC
OK, we found it:

 [libpanelapplet]$ ls -l src/enums.* libpanelappletmm/private/enums_p.h
 -rw-r--r-- 1 daniel daniel  175 2008-01-28 19:51 libpanelappletmm/private/enums_p.h
 -rw-r--r-- 1 daniel daniel  992 2007-09-10 17:07 src/enums.ccg
 -rw-r--r-- 1 daniel daniel 1294 2008-01-28 19:58 src/enums.hg

Because the time stamp of enums_p.h says that it's older than its dependency enums.hg, make attempts to rebuild it.  Since we ship generated sources in the tarball releases and disable the code generation rules in the Makefile, make doesn't how to rebuild the file and aborts.

Just in case, I compared a regenerated enums_p.h to the older file from the tarball, and there were no changes.  Thus, even if any change was made to the content of enums.hg, it didn't have any effect on the gmmproc output.

As a work-around, it should be enough to do

  touch libpanelapplet/libpanelappletmm/private/enums_p.h

before running make.
Comment 5 Priit Laes (IRC: plaes) 2009-05-07 13:56:07 UTC
Created attachment 134193 [details] [review]
fix-generated-headers-issue.patch

I added this "touchy" stuff to build. Now things compile and also distcheck passes. :)
Comment 6 Priit Laes (IRC: plaes) 2009-05-07 14:03:23 UTC
(In reply to comment #5)
> Created an attachment (id=134193) [edit]
> fix-generated-headers-issue.patch
> 
> I added this "touchy" stuff to build. Now things compile and also distcheck
> passes. :)
> 

Now that I tested it a bit more, it breaks even harder than before...
Comment 7 Daniel Elstner 2009-05-07 14:26:07 UTC
It's just this one release tarball that is broken.  It would be fixed by simply doing a new release, without changing anything.  The work-around I mentioned was meant to be used with the broken tarball as-is, just to get it to build.  It might make sense for a distribution package to use that hack in its build scripts as a temporary work-around, but it definitely shouldn't go into libpanelappletmm itself.
Comment 8 Hubert Figuiere (:hub) 2009-05-16 19:47:11 UTC
various report say it is actually fixed.

marking as such.
Comment 9 Priit Laes (IRC: plaes) 2009-05-17 12:24:09 UTC
(In reply to comment #8)
> various report say it is actually fixed.

Says who? 

git clone, autogen, configure and make still fail with exactly the same  error as the one I opened this bug...
Comment 10 Daniel Elstner 2009-05-17 12:47:15 UTC
(In reply to comment #9)
> 
> git clone, autogen, configure and make still fail with exactly the same  error
> as the one I opened this bug...

That's most likely because you run ./configure a second time (autogen.sh already executes it) but without the --am-maintainer-mode flag. Since libpanelappletmm ships with generated source code in the tarball, the Makefile rules for running gmmproc are only activated when --am-maintainer-mode is specified.

Just omit the second invocation of ./configure and building from git should work. Also, Hub made a new tarball release which should build fine without maintainer mode. If it doesn't, feel free to reopen the bug.