Hi,
IMO you should really consider using %configure, as it will pass all the necessary flags that are common to every autoconf project, and you don't need to do it yourself.
The problem here is two-fold: a) In many cases the standard autoconf defaults are already correct, b) In other cases, the line %configure expands to is not correct. And: c) Having to add the required options manually is not necessarily a bad thing, as it can prevent some common mistakes. And it can help tracking which degree of customization is actually really needed in a package.
Sorry, but I totally disagree here.
All I set is %define _prefix /usr (and even that is optional, I rather to so for deterministic reasons)
All the rest is computed properly and is always correct.
I couldn't disagree more. This would be nice if it were the case, but it isn't. Not always, actually not even in most cases and the worst problem about it is that people think it computes things correctly although it doesn't. If it's even possible to call it a computation what %configure does, it's a very, very simple one, to say the least. In detail. A simplified excerpt of what %configure becomes: ./configure \ --prefix=%{_prefix} \ --exec-prefix=%{_exec_prefix} \ --bindir=%{_bindir} \ --sbindir=%{_sbindir} \ --sysconfdir=%{_sysconfdir} \ --datadir=%{_datadir} \ --includedir=%{_includedir} \ --libdir=%{_libdir} \ --libexecdir=%{_libexecdir} \ --localstatedir=%{_localstatedir} \ --sharedstatedir=%{_sharedstatedir} \ --mandir=%{_mandir} \ --infodir=%{_infodir} --prefix=%{_prefix}: OK, nothing to worry about. Will be redefined if necessary. --exec-prefix=%{_exec_prefix}: Unncessary, already defaults correctly to %{_prefix}. Different values for %{_prefix} and %{_exec_prefix} are never used. --bindir=%{_bindir}: OK, nothing to worry about, but completely unnessary to specify. --sbindir=%{_sbindir}: OK, nothing to worry about, but completely unnessary to specify. --sysconfdir=%{_sysconfdir}: Dangerous! Defaults to /etc, correct for most packages whose %{_prefix} is / or /usr, but not all. Almost always wrong for packages whose %{_prefix} is neither / nor /usr, with some interesting exceptions. --datadir=%{_datadir}: OK, nothing to worry about, but completely unnessary to specify. --includedir=%{_includedir}: A reasonable default, no need to specify explicitly. --libdir=%{_libdir}: OK for the majority of packages, but wrong for some exceptions. --libexecdir=%{_libexecdir}: Always wrong. Must be redefined, highly dependant on the package. Candidates are: %{_prefix}/lib/%{name} %{_prefix}/lib %{_sbindir} %{_libdir}/%{name} (very rarely, indicates a bug in the package) %{_libdir} (very rarely, indicates a bug in the package) --localstatedir=%{_localstatedir}: Defaults to /var. Always wrong! Candidates are: /var/lib/%{name} /var/lib /var%{_prefix}/%{name} /var%{_prefix} /var/cache/%{name} /var/cache --sharedstatedir=%{_sharedstatedir}: Defaults to /var/com. Always wrong! Candidates are the same as for --localstatedir. --mandir=%{_mandir}: Correct for packages whose %{_prefix} is either /usr or /opt/gnome, but wrong for all others, especially / and /usr/X11R6. --infodir=%{_infodir}: Same as --mandir. And now I really fail to see the advantage of %configure, given the fact that it expands to a line which is partly correct and helpful, partly correct and unnecessary and partly inherently wrong because there's no way to guess the "right thing" automatically. This includes especially --libexecdir, --localstatedir and --sharedstatedir. They are not guessed correctly by default and I have no idea how to improve the guessing in a generic way. To summarize, %configure looks to me like a typical example of "bloat" which is used just because it exists: It tries to make things easier, but actually makes a lot of things more complex. Redefining the macros which are wrong by default doesn't make anything more readable, IMHO it actually makes things more cryptic than an explicit ./configure invocation. Sometimes it can be dangerous because packagers might think that %configure automagically does the "right thing" for them even if it doesn't, and as a user, it's more difficult for me to follow where the package differs from what I would get by running "./configure ; make ; make install" myself.
1) KDE For KDE you should not use %configure but unsermake instead:
Yes, this is clear. And it shows nicely the difference between KDE and most other projects: All KDE packages use exactly the same set of options, so a macro would make sense here, but other packages are less streamlined and might need special attention.
# note: "make" and not "%__make" when using unsermake !
See, this is such an example where macros make things more cryptic, not easier. %{__make} expands to /usr/bin/make, but doesn't help here, and actually helps nowhere. Why not always use make directly? %{__make} would be useful if it included the -j flags automatically, but even then it would be dangerous because -j flags actually break some packages. If it's just /usr/bin/make, what's the benefit, that it looks more RPMish, that it doesn't let you override the make binary with another one in the PATH, something else?
2) GNOME %define _prefix /opt/gnome %define _sysconfdir /etc/opt/gnome
Yes, often. And then, there are the exceptions. Like yumex, it lives in /opt/gnome, but still needs --sysconfdir=/etc because otherwise it doesn't find yum's config files. An example for the idea that carefully and individually looking at what each package really needs might not be such a bad idea. And there is also the opposite, applications that live in /usr and still need --sysconfdir=/etc/opt/gnome because of gconf.
%build export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 %configure \ --disable-schemas-install %__make %{?jobs:-j%{jobs}}
%install export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 %makeinstall
Duplication, either set the environment variable (only during %install, not %build) or use the configure option (but this is something else, not related to %configure).
I only very, very rarely encountered packages that must install into %{_prefix}/lib instead of %{_libdir} (= %{_prefix}/%{_lib}).
http://ggap.sourceforge.net/ is an example. And many, if not all Mono/C# applications, and there are more, definitely.
When that happens, nothing easier than
%define _prefix /usr %define _libdir %{_prefix}/lib ... %build %configure ...
Yes, but why? This is what I consider being "bloat". ./configure already does the "right thing" by default in such a case, which is wrong elsewhere, then let's make a wrapper called %configure around it that fixes other packages, but breaks this one and finally fix the fix that never fixed anything right in the spec file. It's not nice.
What wrong ones ? I never, ever had to "fix" those options. And I currently maintain 700 packages.
The frequently wrong ones are especially: --libexecdir, --localstatedir, --sharedstatedir, but not only these. It's not that much a matter of the number of packages. Of course there are a few packages among the 700 with wrong paths in them. The point is more the "bloat" I described above, adding stuff that is never ever used in many packages, parts of which are even always wrong by design, and which makes following the difference between the package and a "normal" compilation more tricky. Something else I dislike about %configure is that it doesn't support cases where builddir != srcdir, e.g. building object files in a subdirectory instead of the top-level directory of the source tree. OK, one might ask, why would someone want to separate builddir and srcdir while making RPMs if all the stuff is deleted afterwards anyway, but why not, and why start using a macro that is too limited to support simple out-of-source builds? Maybe we're lucky and the problem will vanish anyway by all packages using %__cmake, %__scons and friends next year. ;) Andreas Hanke -- Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer