Ludovic Courtès writes: > Hi! > > Roel Janssen <r...@gnu.org> skribis: > >> Alex Kost writes: >> >>> Tomáš Čech (2016-08-27 09:57 +0300) wrote: >>> >>>> On Fri, Aug 26, 2016 at 09:48:36PM +0200, Roel Janssen wrote: >>>>>Dear Guix, >>>>> >>>>>Due to an old Automake version (1.13), running the `./configure' phase on >>>>>CentOS 7 fails with: >>>>> >>>>>> autoreconf: running: automake --add-missing --copy --force-missing >>>>>> configure.ac:21: warning: The 'AM_PROG_MKDIR_P' macro is deprecated, and >>>>>> its use is discouraged. >>>>>> configure.ac:21: You should use the Autoconf-provided 'AC_PROG_MKDIR_P' >>>>>> macro instead, >>>>>> configure.ac:21: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your >>>>>> Makefile.am files. >>>>>> Makefile.am:422: warning: AM_GNU_GETTEXT used but 'po' not in SUBDIRS >>>>>> automake: error: cannot open < ./%D%/guix.texi: No such file or directory >>>>>> autoreconf: automake failed with exit status: 1 >>>>> >>>>>(It does not replace %D% with the appropriate directory..) >>>>> >>>>>The attached patch replaces each instance of %D%, which I believe stands >>>>>for the current subdirectory from the project root, with the appropriate >>>>>directory. With these changes, I've been able to compile GNU Guix on >>>>>CentOS 7. >>>>> >>>>>I am not sure how this change impacts custom configure options, so I >>>>>would like to ask someone with more Automake knowledge and experience to >>>>>elaborate on the possible downsides of applying this patch. >>>>> >>>>>If this change is acceptable to the project, I will update the commit >>>>>message to a more detailed and conforming message. Suggestions are >>>>>welcome here though. >>>>> >>>>>What do you think about making Guix compilable on this "stable" >>>>>distribution? :-) >>>> >>>> I'd prefer to keep this patch in CentOS (or similar distribution with >>>> outdated software) as distro specific. I can assume that CentOS 8 >>>> won't need it and you can just drop it for newer releases. >>> >>> I also think this patch should stay on the CentOS side. Roel, what you >>> suggest is a revert of commit c0d2e7b: >>> >>> http://git.savannah.gnu.org/cgit/guix.git/commit/?id=c0d2e7b197a3c511eb1bf60b61ee6fdc673e36f4 >> >> Ha! I hadn't seen that commit. It is indeed a revert of this commit. >> >> Let me rephrase my thought: >> I don't see any good reason to break compatibility with well established >> distributions. And the commit message does not state why a macro is >> better than spelling out the relative path. > > Use of %D% was discussed here: > > https://lists.gnu.org/archive/html/guix-devel/2016-05/msg00641.html > > In general, I’m in favor of using the latest build tools available (the > autotools), because I think it’s reasonable to ask developers to have > the latest available. If needed, they can install the Guix binary > tarball and get the latest tools from there.
So, for CentOS 7 users you suggest that to compile GNU Guix, people need to first install the GNU Guix binary? Is that really easier than applying and maintaining this change? I think that we should support the version of Automake shipped with CentOS 7. > Now, I also agree that we don’t want to needlessly break compatibility. > > This particular case looks borderline to me. I’m in favor of the status > quo, at least to avoid all the merge conflicts that reverting would > entail, and because the workarounds that Tomáš and Florian suggest look > reasonable. Right, so that will result in us not being able to compile GNU Guix on CentOS 7 without additional instructions. (I do not intend to create and maintain an RPM. I want to use the Guix package management system, not RPM!) The patch is really simple, so it should be simple to apply, in whatever form. > WDYT? So, what we're having here is kind of anti-GNU: We prefer the developer's comfort (for unlikely but possible future maintenance burden) over the user's comfort (for getting GNU Guix to compile on a well established distribution). As it seems to be very difficult to fix a simple issue, I think I'll just have to give up trying. Thanks for the replies. Kind regards, Roel Janssen
