Description of problem: doxygen.spec %build section breaks rebuild with a custom %{_prefix} due to configure --make argument. Version-Release number of selected component (if applicable): 1.8.5-1 How reproducible: Steps to Reproduce: 1. Create an alternate rpm build area in a user directory: mkdir -p ~/rpmbuild/{BUILD,RPMS/i586,RPMS/noarch,RPMS/x86_64,SOURCES,SPECS,SRPMS,tmp} 2. Update ~/.rpmmacros to contain: %_topdir %(echo ${HOME})/rpm %_prefix %(echo ${HOME}) %_tmppath %{_topdir}/tmp 3. Attempt to rebuild the doxygen source rpm: rpmbuild --rebuild doxygen-1.8.5-1.mga4.src.rpm (As needed resolve any build dependencies and retry) 4. Observe build failure and note presence of a username in the path to the make utility. For example: ... cd addon/doxywizard ; /home/kbulgrien/bin/make /bin/sh: /home/kbulgrien/bin/make: No such file or directory make: *** [doxywizard] Error 127 error: Bad exit status from /home/kbulgrien/rpm/tmp/rpm-tmp.96157 (%build) 5. Locate the issue in the doxygen.spec file: grep --context=4 -- --make ~/rpm/SPECS/doxygen.spec For example: %build ./configure \ --prefix %{_prefix} \ --make %{_bindir}/make \ %if %with qt4 --with-doxywizard %endif 6. Wonder why the --make argument specifies a path to the make utility based on %{_prefix}. If a system has make installed in /usr/bin, a system admin or user might very well want a custom build of doxygen installed in an alternate location, but does expect the build tools to be located in the normal place for the distribution. One way to workaround this issue is to remove the line containing --make from the doxygen.spec file. Reproducible: Steps to Reproduce:
Keywords: (none) => TriagedCC: (none) => fundawang, shlomif, thierry.vignaud
Should be fixed in doxygen-1.8.5-2.mga4 . Please confirm. However, in general, I'm not sure that make such customisations to core macros is a good idea, but I'm willing to accommodate for this stuff in this occasion.
What I described is a change to a .spec file. I am confused about why customization to a "core macro" is mentioned. Admittedly I am not well versed in packaging, but I am confused why one would explicitly pass in a path to ./configure to tell it where make is. The point of ./configure is to find out what the system has. I could see how conceptually passing in a path based on $(which ) results might be useful if the ./configure expected to use a make tool with a particular name, but the command line above specifies a vanilla make tool, so seems completely pointless.
Oh, I guess you mean you are uncomfortable with my messing around with ~/.rpmmacros, and that you aren't sure making packaging changes to let Mageia users do that is one of a packager's responsibilities. I see that point, so I appreciate your patch, and in general, agree. I thought, however, that the idea of hard-coding paths to make is unwise and seems to run counter to the idea behind the ./configure mechanism (but welcome being introduced to an alternate viewpoint). I would not have filed a bug if it was simply a matter of making it convenient for me to play mix and match with RPMs from different sources. If it helps, I do periodically package RPMs for one open source project, so I have what it takes to deal with minor issues (without filing bugs) when the issues do not necessarily seem to go against an important principle.
Resolving as FIXED.
Status: NEW => RESOLVEDResolution: (none) => FIXED