On Fri, Nov 18, 2005, Florin Iucha wrote: > [...] > My problem is that some openpkg packages appear to conflate the build > time dependencies with run time dependencies, and it does that in an > inconsistent manner: why does db depend on gcc but subversion and > pdksh do not?
It is consistent, but perhaps not easily traceable. "db" in particular requires "gcc" under build-time because it chooses the underlying mutex implementation for Berkeley-DB as GCC specific assembly versions on most platforms. "subversion" and "pdksh" do not depend on "gcc" simply because they are known to build also without GCC (mainly because they both do not depend on GCC features and contain no C99 or latest C++2003 stuff). If a package builds with an arbitrary C94 compiler we do not depend GCC as we assume (and know) that any vendor compiler (on all of our supported platforms) at least support C94. If anything more is required we depend on our GCC 4 which provides this. > Besides, most of the software packages you open-package already > support (via autoconf/automake & friends) being compiled with native > build environments so hard-depending on GNU make and GNU cc does not > help in a significant way. You are being overly-protective here - > people who just "want it to work" will get binaries, people who pass > --use_cc are expected to know what they are doing, or able to quickly > learn ;) > > BTW, I have already added > %l_cc /opt/SUNWspro/bin/cc > do my .rpmmacros file but I expected the system to remember that I > have passed --use_cc to the bootstrap procedure. > > Please do not take this as "drive-by criticism" of the project. I > appreciate the work that you are doing. My reason to compile with > the native compiler is trying to get the most out of this aging > machine. I fully see your point and accept your wish. The basic problem for OpenPKG just is that "optimizations for a particular platform" (like choosing already existing vendor programs or choosing a vendor compiler) are in great conflict with "being self-contained and consistent across all platforms". Sure with enough conditionals in all packages both could be achieved, but it results in really nasty packaging code. Just take the "db" example: there is already an ugly case/esac construct in db.spec for the GCC assembly stuff. If we want now to even allow a non-GCC compiler to be used we need a lot of of additional if-clauses in this package (remember that we support nearly 20 platforms and each one has a different vendor compiler or at least vendor compiler version). All of those platform specific hackings are making our packaging unclean and ugly and hence we try very hard to avoid it at all. At the obvious but not easily avoidable cost of being not flexible enough to allow specific platform optimizations. Our general design decision is that cleanness and maintenability is greatly preferred over any platform specific optimizations (see also http://www.openpkg.org/doc/slideset/openpkg/slide-012-l.html). Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com ______________________________________________________________________ The OpenPKG Project www.openpkg.org User Communication List openpkg-users@openpkg.org
