GNOME Bugzilla – Bug 311874
Don't use the mkinstalldirs script
Last modified: 2005-11-24 19:05:51 UTC
Makefile.in.in uses the script mkinstalldirs on several places. This is no longer safe, as the script is deprecated and Automake >= 1.8 doesn't install it. The script is used, if it is already present in the tree, but "automake -a" doesn't bring it to a fresh tree. With most Gnome projects, the script mkinstalldirs is installed by glib-gettextize. But the combination of Automake >= 1.8 plus GNU gettext might cause problems. I suggest to follow the practice of Automake 1.9.x and set mkinstalldirs = $(install_sh) -d and then use $(mkinstalldirs) consistently.
Created attachment 49890 [details] [review] the patch This patch cleans up the mkinstalldirs usage in Makefile.in.in. To be applied after the patch from bug #311129.
So, we need to support both possible values for $(mkinstalldirs) I think. Automake uses the script, if it exists, and given that all the gnome projects in the desktop use glib-gettextize, as far as I know, this method will be used for all of them. So, it seems like we should probably not have inconsistencies with the rest of the mkinstalldirs usage in source trees.
I don't think we have to support two alternatives. There will also be some differences in style between Automake generated makefiles and our hand-crafted Makefile.in.in. That's inevitable. (At least for now; future versions of gettext will be better integrated with Automake and Makefile.in.in will be dropped. But this solution is not ready yet.) Automake >= 1.8 defines the variable $(mkinstalldirs), for backward compatibility, but Automake-generated rules don't use it. Our code should be similar, ... Patch follows.
Created attachment 49944 [details] [review] updated patch This time, I used $(mkdir_p) instead of $(mkinstalldirs) in the rules. With this modification, our makefile rules are even more similar to the rules generated by Automake >= 1.8. Automake determines the value of mkdir_p at configure time. We could do that too, but I don't think it's worth it. I see mo problems with mkdir_p = "$(install_sh) -d". 1) It's absolutely portable to all platforms and all Automake versions. 2) The readability of Makefile.in.in is much better than with the previous version. 3) It doesn't decrease readability of make output either: the value of mkdir_p is displayed only once. Moreover "install -d" should be fairly known. 4) Performance: (n+1) times we invoke shell script install_sh instead of mere /bin/mkdir. (n denotes the number of installed catalogs.) I don't think we should try to optimize here. OK to commit?
"all Automake versions" -- I should have said Automake >= 1.5. But I don't think we should bother about Automake 1.4.
Ah. We should not use "$(install_sh) -d", I don't think. Shouldn't we just have IT_PROG_INTLTOOL require AM_PROG_MKDIR_P, and do "mkdir_p = @mkdir_p@" in Makefile.in.in? It seems more appropriate to me.
Yes, that would be also possible. But mkdir_p was introduced in Automake 1.8, so we - either have to require Automake >= 1.8, - or have to put a copy of AM_PROG_MKDIR_P to intltool.m4, to be called is Automake doesn't provide it. The former probably is not possible. The latter would work, but I don't think it's elegant. I still think that the most elegant solution is to use install-sh, which is readily available. Yes, it's a shell script, while @mkdir_p@ calls /bin/mkdir, but we shouldn't try to optimize here. (Please note that if "mkdir -p" doesn't work, "$(install_sh) -d" is used as the fallback for mkdir_p.)
Created attachment 51650 [details] [review] updated patch Regenerated version of the patch. OK to commit?
Committed.