Bug 744766 - Disabling silent rules breaks non-autotools builds
Summary: Disabling silent rules breaks non-autotools builds
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: redhat-rpm-config
Version: rawhide
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ---
Assignee: Colin Walters
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 739012 744731 744754 756997 756998 756999
TreeView+ depends on / blocked
 
Reported: 2011-10-10 11:57 UTC by Stephen Gallagher
Modified: 2016-09-22 18:00 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-09-22 18:00:06 UTC
Type: ---


Attachments (Terms of Use)

Description Stephen Gallagher 2011-10-10 11:57:52 UTC
Description of problem:
The default specification for %configure in redhat-rpm-config now specifies --disable-silent-rules for all builds. This works fine for autotools builds, but some build systems (notably the samba WAF build system) does not ignore unknown configure options. This results in a FTBFS state for these packages on Rawhide right now.

Version-Release number of selected component (if applicable):
redhat-rpm-config-9.1.0-21.fc17

How reproducible:
Every time

Steps to Reproduce:
1. Attempt to build libtdb, libtalloc or samba4 (probably other packages as well) with koji on Rawhide.
  
Actual results:
+ ./configure --build=i386-redhat-linux-gnu --host=i386-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --disable-silent-rules --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --disable-rpath --bundled-libraries=NONE
waf [command] [options]
Main commands (example: ./waf build -j4)
  build      : builds the project
  clean      : removes the build files
  configure  : configures the project
  dist       : makes a tarball for distribution
  distcheck  : checks if the sources compile (tarball from 'dist')
  distclean  : removes the build directory
  install    : installs the build files
  reconfigure: reconfigure if config scripts have changed
  test       : run tdb testsuite
  uninstall  : removes the installed files
waf: error: no such option: --disable-silent-rules
error: Bad exit status from /var/tmp/rpm-tmp.2Rxf1u (%build)
    Bad exit status from /var/tmp/rpm-tmp.2Rxf1u (%build)
RPM build errors:
Child returncode was: 1
EXCEPTION: Command failed. See logs for output.

Expected results:
Successful build

Additional info:
While I appreciate the intent of setting this flag, I think the more effective way might be to change %{?_smp_mflags} (or provide a new macro for standard make flags) and set the environment variable V=1 for builds.

Comment 1 Panu Matilainen 2011-10-10 12:19:52 UTC
Reassigning to Colin Walters who introduced this change. FWIW I'm not the biggest fan of this whole thing.

Comment 2 Stephen Gallagher 2011-11-02 18:53:46 UTC
Any word on this issue?

Comment 3 Stephen Gallagher 2011-11-07 14:05:43 UTC
This is causing FTBFS on multiple packages. Please revert it.

Comment 4 Andreas Schneider 2011-11-08 14:42:23 UTC
This should be changed on the make level so make V=1 and not using the configure option which will, according to the documentation, only work if the developer adds it to his configure.ac file.

Comment 5 Kamil Dudka 2011-11-08 14:55:04 UTC
I agree, but using %{?_smp_mflags} for this purpose sounds wrong to me.

Comment 6 Stephen Gallagher 2011-11-08 15:05:00 UTC
(In reply to comment #5)
> I agree, but using %{?_smp_mflags} for this purpose sounds wrong to me.

Yeah, I agree. Maybe we might want to implement %{?_std_mflags} which would expand out to 
%{?_smp_mflags} V=1

Comment 7 Colin Walters 2011-11-09 13:38:41 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > I agree, but using %{?_smp_mflags} for this purpose sounds wrong to me.
> 
> Yeah, I agree. Maybe we might want to implement %{?_std_mflags} which would
> expand out to 
> %{?_smp_mflags} V=1

Then you're back to patching every package though that uses autotools and AM_SILENT_RULES.

If that's the way you guys want to go for RPM, fine by me.  My own opinion is here:

http://people.gnome.org/~walters/docs/build-api.txt

Comment 8 Kamil Dudka 2011-11-09 15:47:38 UTC
> http://people.gnome.org/~walters/docs/build-api.txt

Is this document something that upstream maintainers follow?  How does it apply on projects not based on autotools?

Comment 9 Colin Walters 2011-11-10 19:14:44 UTC
(In reply to comment #8)
> > http://people.gnome.org/~walters/docs/build-api.txt
> 
> Is this document something that upstream maintainers follow?  How does it apply
> on projects not based on autotools?

I have been slowly changing bits of the GNOME dependency stack to implement it.  Almost everything in GNOME git now implements it.  I recently added a patch to mesa.  Is it slow going?  Yes.  Is it worth doing?  Totally.

It's usually not very hard to implement if not using the autotools, but it depends on your project.

(Also at some point I plan to write generic "adapters" so that if e.g. we detect the current source tree is using Python distutils, we automatically drop in a configure and Makefile that in turn just call into distutils).

Comment 10 Ville Skyttä 2011-11-24 22:32:20 UTC
Sadly, it seems that Colin's patch has been reverted in git by Dennis.  IMO it's a mistake to hold improvements to %configure hostage to some build systems that choke on something they don't understand; packages using such systems shouldn't quite probably be using the %configure macro in the first place.  Even though the one in redhat-rpm-config doesn't say it, the one shipped with rpm (/usr/lib/rpm/macros) clearly states in its comments that it is intended for running "autoconf configure".

Please consider adding --disable-silent-rules back, and fixing the few packages/build systems that choke on it instead as appropriate.

Comment 11 Kamil Dudka 2011-11-25 10:24:19 UTC
(In reply to comment #10)
> Please consider adding --disable-silent-rules back, and fixing the few
> packages/build systems that choke on it instead as appropriate.

On how many packages would changing the %configure macro take a (positive?) effect?  Do you have any stats?

Comment 12 Ville Skyttä 2011-11-25 19:12:17 UTC
No, but I have encountered a few, and I have some other options that I will be suggesting to %configure soonish, and I'm available to help with fixing packages that choke on unknown options one way or another.

BTW it's not that long ago when --disable-dependency-tracking was added to %configure; at that time packages some packages whose build broke were simply fixed, so there is a precedent.

Comment 13 Kamil Dudka 2011-11-25 21:05:48 UTC
Changes like this break building unpatched (e.g. RHEL) packages on up2date system.  Developers then need to use mock in cases where rpmbuild would be sufficient, or they need to debug tricky build failures.

Comment 14 Colin Walters 2011-12-01 18:10:09 UTC
(In reply to comment #13)
> Changes like this break building unpatched (e.g. RHEL) packages on up2date
> system.  Developers then need to use mock in cases where rpmbuild would be
> sufficient, or they need to debug tricky build failures.

Breaks...oh you mean like building a waf-based package on Fedora for RHEL?

Yeah, well, Comment #10 is a better restatement of my position.

Comment 15 Ville Skyttä 2011-12-01 19:35:20 UTC
If comment 13 was a strong consideration (think bigger picture than just %configure as you already mentioned changes "like this"), then moving Fedora forward in the first place would be much harder than it is now -- we'd need to hold back on backwards incompatible improvements or provide bugwards compatibility cruft with $something pretty much indefinitely.  I think that's very much a non-objective for Fedora.

Comment 16 Stephen Gallagher 2011-12-01 19:54:26 UTC
The samba project has been convinced to add --disable-silent-rules as an (ignored) option for its WAF builds. You can re-enable this feature in %configure if you want.

Comment 17 Colin Walters 2011-12-01 20:05:00 UTC
(In reply to comment #16)
> The samba project has been convinced to add --disable-silent-rules as an
> (ignored) option for its WAF builds. You can re-enable this feature in
> %configure if you want.

I forget if I linked here, but I still think the best fix for waf is:

https://code.google.com/p/waf/issues/detail?id=1023

Comment 18 Colin Walters 2011-12-01 20:07:08 UTC
Though I could be convinced a better approach would be for RPM (or other meta-build system) to run ./configure --help and grep for the availability of options before using them.

Comment 19 Fedora End Of Life 2013-04-03 18:07:24 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19


Note You need to log in before you can comment on or make changes to this bug.