GNOME Bugzilla – Bug 686839
mkinstalldirs: Move to glib-mkinstalldirs
Last modified: 2012-10-29 13:40:33 UTC
This is installed by automake. By maintaining it in git, we create merge conflicts as people build with different versions of automake. For apparently historical reasons, it's actually installed into the target system for use by glib-gettext. So let's keep it, just renamed.
Created attachment 227222 [details] [review] mkinstalldirs: Move to glib-mkinstalldirs
Pretty sure mkinstalldirs is only needed on systems we don't care about t all, and we can just use 'mkdir -p' in glib-gettext...
If automake is generating this file then why do we care about having it in version control? It'll appear as soon as we autogen....
(In reply to comment #2) > Pretty sure mkinstalldirs is only needed on systems we don't care about t all, > and we can just use 'mkdir -p' in glib-gettext... Not trivially, if you look at what (glib-)gettextize do with this file: they copy it into the project they're assimilating. At least, we have to strip mentions of mkinstalldirs from the po/Makefile.in.in we ship, as well.
(In reply to comment #3) > If automake is generating this file then why do we care about having it in > version control? It'll appear as soon as we autogen.... Its not about us, it is about 3rd party modules that are using glib-gettextize to gettextize themselves. You don't know what their autogen does, or if they even have one...
(In reply to comment #5) > (In reply to comment #3) > > If automake is generating this file then why do we care about having it in > > version control? It'll appear as soon as we autogen.... > > Its not about us, it is about 3rd party modules that are using glib-gettextize > to gettextize themselves. You don't know what their autogen does, or if they > even have one... ...but surely these other projects are not calling glib-gettextize out of our frenshly-checked-out-of-git-but-not-autogen'd source tree?
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #3) > > > If automake is generating this file then why do we care about having it in > > > version control? It'll appear as soon as we autogen.... > > > > Its not about us, it is about 3rd party modules that are using glib-gettextize > > to gettextize themselves. You don't know what their autogen does, or if they > > even have one... > > ...but surely these other projects are not calling glib-gettextize out of our > frenshly-checked-out-of-git-but-not-autogen'd source tree? Again, you don't really know if they have an autogen or even use automake. If they don't use automake, then mkinstalldirs is not going to magically appear.
I know that *we* use autogen... this is about what's in the source control of glib... not some random other project...
Sigh. Reread my earlier comments on why this stuff is in our source control. I'll come back to this bug when there's a patch that removes mkinstalldirs from po/Makefile.in.in
One actually kind of evil complication in this whole thing is, quoting /usr/bin/automake: # Distribute and define mkinstalldirs only if it is already present # in the package, for backward compatibility (some people may still # use $(mkinstalldirs)). Emphasis on "only if it is already present in the package".
Anyways so can someone please be explictly clear here: First, does this patch solve the problem and not introduce any new issues? Second - if the first is true, are we saying the patch could simply be better in some way? If so, please explain? Is the idea that we could somehow avoid shipping a version of mkinstalldirs in GLib at all? If so, that seems to be drastically complicated by comment #10.
(In reply to comment #11) > Anyways so can someone please be explictly clear here: > > First, does this patch solve the problem and not introduce any new issues? No, it will break people (other than glib) who use glib-gettextize, because now glib-gettextize will create a script called "mkinstalldirs" but a po/Makefile.in.in that looks for "glib-mkinstalldirs". (This is fixable of course, it's just that it's broken in the current patch.) > Second - if the first is true, are we saying the patch could simply be better > in some way? If so, please explain? Is the idea that we could somehow > avoid shipping a version of mkinstalldirs in GLib at all? Yes. Just make po/Makefile.in.in use "mkdir -p" instead. > If so, that seems > to be drastically complicated by comment #10. No, nothing needs mkinstalldirs except po/Makefile.in.in, so if we changed po/Makefile.in.in to not need it, then we don't care whether or not automake decides to create it itself. All that said, bug 308769 suggests that we should just kill glib-gettextize anyway, so we should probably close/dup this and do that instead.
(In reply to comment #12) > All that said, bug 308769 suggests that we should just kill glib-gettextize > anyway, so we should probably close/dup this and do that instead. I ran into issues building GLib on RHEL6 with that. This is something I'd like to keep supporting for a "long time" (at least until RHEL7 GA). Might be fixable though.
Created attachment 227470 [details] [review] mkinstalldirs: Delete from version control Should address comments.
Maybe a better long-term solution is to move to upstream gettext (so upstream po/Makefile.in.in) ? A patch is available in bug #622991
Comment on attachment 227470 [details] [review] mkinstalldirs: Delete from version control seems to work...
(In reply to comment #15) > Maybe a better long-term solution is to move to upstream gettext (so upstream > po/Makefile.in.in) ? A patch is available in bug #622991 Discussion of that was covered a bit above...I was just going for a quick fix so I could run autogen without a modified mkinstalldirs pollution my commits.
Review of attachment 227470 [details] [review]: looks good to me
Attachment 227470 [details] pushed as cff536c - mkinstalldirs: Delete from version control