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 656919 - fix make's dist target
fix make's dist target
Status: RESOLVED FIXED
Product: ghex
Classification: Applications
Component: general
2.90.x
Other All
: Normal minor
: ---
Assigned To: GHex maintainers
GHex maintainers
Depends on:
Blocks:
 
 
Reported: 2011-08-19 16:12 UTC by Rafał Mużyło
Modified: 2011-09-05 22:54 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
clean up legacy cruft (1014 bytes, patch)
2011-08-20 16:25 UTC, Rafał Mużyło
none Details | Review
same patch, git-formated (1.85 KB, patch)
2011-08-26 00:51 UTC, Rafał Mużyło
committed Details | Review

Description Rafał Mużyło 2011-08-19 16:12:44 UTC
Toplevel Makefile.am lists files no longer included (or at least ones that shouldn't be included) breaking dist target.

First, omf.make and xmldocs.make:
these two are just leftovers from old gtk-doc, obsoleted by gnome-doc-utils.make.

Second, intltool scripts: we now require 0.40.0, but ever since gtkbuilder most of gnome required 0.41.0, if not 0.41.1 (the later released about 16 months ago).
In fact, I see 0.41.1 in jhbuild's gnome-external-deps-2.3{0,2}.modules.

Ever since 0.41.0, both the '*.in' entries in EXTRA_DIST and regular in DISTCLEAN_FILES are redundant, as intltool uses system copy of those.
Comment 1 Kalev Lember 2011-08-20 13:56:23 UTC
I don't pretend to know much about gtk-doc. All I can tell is that dist and distcheck work fine for me on Fedora 15 and 16 and certainly aren't broken.

What distro do you use and did you have the gtk-doc package installed when you tried to run 'make dist'?

As usual, patches are welcome.
Comment 2 Rafał Mużyło 2011-08-20 16:25:25 UTC
Created attachment 194298 [details] [review]
clean up legacy cruft

First, sorry, I've made a "typo" there, I meant gnome-doc-utils, not gtk-doc.

Well, this explains yet another difference we both see.

Again, I haven't used that script and part of the bug lies in that script.

I'll just attach the patch, you'll see the reason there.
On a related note: the docs are a bit outdated about it. The general problem with wrappers is that they become a problem once people forget what they wrap.
It was both cruft from old doc layout and gnome1.

Just dig into gnome-common git, if you want to see the details.
Comment 3 Kalev Lember 2011-08-22 08:06:51 UTC
Review of attachment 194298 [details] [review]:

Looks like a very nice cleanup.

Regarding intltool, I belive adding intltool scripts to EXTRA_DIST was no longer needed with 0.40.0, so there's no need to bump the minimum version. See e.g. http://git.gnome.org/browse/gnome-desktop/commit/?id=35b51769

Any chance I could convince you to format the patch with git-format-patch and write up a nice commit message? I would personally also break it up into two separate commits (intltool changes and gnome-doc-utils related), but if you prefer them in one single commit, that's perfectly fine too.
See https://live.gnome.org/Git/Developers#Contributing_patches on how to use git-format-patch.
Comment 4 Rafał Mużyło 2011-08-26 00:51:36 UTC
Created attachment 194760 [details] [review]
same patch, git-formated

On the other hand, you require gtk+-3.0, which is significantly more recent than intltool 0.41.1.

I put the 'foreign' line there again - feel free to drop it.
Comment 5 Rafał Mużyło 2011-08-26 00:58:07 UTC
My point is not only the date and jhbuild stuff, but also the most likely reason for that requirement in jhbuild (as noted in gtk2 docs on libglade migration):

GtkBuilder supports context information in translatable properties in a slightly different way than libglade. Intltool does support this since version 0.41.1.

Not that I think ghex will use GtkBuilder.
Comment 6 Kalev Lember 2011-09-05 22:54:22 UTC
Review of attachment 194760 [details] [review]:

Thanks. I ended up splitting it into two separate commits as these were really two logically separate changes. Pushed to master as 122ab524 and cb1f24c6.