Red Hat Bugzilla – Bug 152136
%configure in .spec file cannot be commented out
Last modified: 2007-11-30 17:11:02 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050302 Firefox/1.0.1 Fedora/1.0.1-1.3.2
Description of problem:
I wrote a spec file which didn't need a ./configure run in the %build section, and so I commented out the %configure line like this:
However, which I build the package using rpmbuild, it still tries to run configure, which of course throws an error:
/var/tmp/rpm-tmp.77728: line 36: ./configure: No such file or directory
However if I just delete the # %configure line (rather than just comment it out) it build normally.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. build a spec file
2. comment out the %configure line
3. run rpmbuild
Actual Results: the rpmbuild fails with "./configure: No such file or directory"
Expected Results: rpmbuild should not have attempted to run ./configure, and should have completed without error.
Comment out by doubling the % character, as in
How is this NOTABUG? What little documentation is available for the rpm spec
file says using an octothorp (#) in front of a line should make it ignored.
This doesn't happen. The documentation says nothing about "except if its a
%configure then you have to add an octothorp and an extra percent sign." This
Macros are expanded everywhere, so multiline macros such as configure only get a
comment on the first line. The documentation fails to make that clear
http://www.rpm.org/max-rpm-snapshot/ch-rpm-specref.html for updated
documentation - to see for yourself:
rpm -E '#%configure'
rpm -E '#%__tar'
Why don't we just have the macro processor ignore commented lines as well? Seems
like that would be simpler than having to remember if a macro was multiline or
not. It would also prevent things mysteriously breaking if a macro got changed
from a single line to a multiline. It's the DWIMy thing to do. Do we gain
anything by expanding macros in comments?
The problem is that what defines a comment in the scriptlets? Though most, as
its the default use /bin/sh as their scriptlet interpretter, you can specify an
alternate interpretter. # is not a comment in all scripting languages (many
but not all). So yes, at least within scriptlets there is something to be
gained by expanding macros after a #. This, BTW, is very simular to how the m4
macro processor works.