Re: USE_CMAKE in meta-pkgs/kde4/kde4.mk

[brook%biology.nmsu.edu@localhost (Brook Milligan)]

Greg Troxel writes:
 > If it's not KDE policy that every program that uses KDE has to use
 > cmake, this still seems excessive.  But if it's ?= and one could set
 > USE_CMAKE=no, then I don't object.

Perhaps this is pretty much over nothing, as I'm not sure I care
particularly other than that the suggestion I made does simplify other
packages and factoring common code to simplify packages is one of
pkgsrc's approaches to increasing robustness.  It is also true that
the comment at the beginning of kde4.mk is the following:

# This Makefile fragment is included by packages that use the KDE4
# configure-and-build process.

Since the "KDE4 configure-and-build process" is exactly cmake, it
seems that anyone including this file to accomplish anything related
to what this comment suggests would in addition have to define
USE_CMAKE=yes.  Having to do both seems totally redundant.

Baring any oddities that have crept in since 2011Q2 time, current
practice seems to support this contention, i.e., all existing packages
do both and are therefore needlessly redundant.

Are there any use cases to be considered that suggest a situation in
which one would want to "use the KDE4 configure-and-build process" but
not want to use cmake?  What would that even mean?

Finally, note that at this point, allowing USE_CMAKE=no would require
changing the stuff in mk/configure/configure.mk, as that is triggered
by defined/undefined not what the value is defined to be.  I contend
that this is needless complexity given the known use cases.

In the end, I think there is a distinction between packages that "use
KDE" (I read this to be, depend perhaps loosely on some component of
kde) and packages that "use the KDE configure-and-build process" (I
read this to be, depend probably quite tightly on the kde cmake
variables).  There is no kde policy about using cmake or especially
about using kde4.mk.  Further, there are other mechanisms to satisfy
the former dependency and if in practice they end up duplicating the
part of kde4.mk that is not about cmake, the obvious solution is to
refactor that into two files.  I also think that the refactoring I
suggested here will benefit the existing set of use cases.
Nevertheless, I am happy to be shown some concrete use cases that
indicate this change not be done.

Thus, at this point I'm not sure how to read the "I don't object"
comment (or actually its implied converse) vis-a-vis what the next
step is.  I feel that a compelling argument suggests the refactoring
change, but am willing to be bludgeoned into seeing why that
conclusion is incorrect.

Cheers,
Brook