# utils/Makefile.in --- xscreensaver, Copyright (c) 1997 Jamie Zawinski.
# the `../configure' script generates `utils/Makefile' from this file.
+
+# The utilities in this directory are used mostly by the demos in ../hacks/.
+# The Makefile in that directory builds executables by simply referencing
+# the .o files in this directory.
+
+
+##############################################################################
+#
+# Some rambling about dynamic libraries follows, ignore it if you don't care
+# (which is almost assuredly the case.)
+#
+#
+# It would probably be sensible to just build a single .a file in this
+# directory, and link the hacks against that (statically.) I haven't done
+# that for two reasons: first, it works now, and why fix what ain't broke;
+# second, it wouldn't actually improve anything for the end user (it would
+# just make the Makefiles be a little smaller.)
+#
+# People sometimes suggest that the stuff in this directory should be in a
+# dynamic library, and that the hacks should be linked dynamically against
+# it. I haven't done this for a number of reasons:
+#
+# * First, the only thing that would improve would be disk space, in that
+# the executable files themselves would be smaller. That's it. Many other
+# things would get worse if we used a dynamic library:
+#
+# * Complication of installation procedures: suddenly, before any of the
+# hacks will work, you need to have a dynamic library installed, and
+# the system configured to use it. This is, basically, rocket science.
+# Most people don't know how to do this, it's a huge pain, and on many
+# systems, it requires root access.
+#
+# * Complication of the Makefile: every system builds dynamic libraries
+# differently. Every compiler takes different flags. I don't want to
+# do the hand-holding for the scores of Unix systems and compilers on
+# which people try to build this program.
+#
+# * Reduction of maintainability: gdb is remarkably bad at dealing with
+# debug info in dynamic libraries, and when debugging a hack, one would
+# constantly be fighting the linker and the debugger (or linking
+# statically when debugging.)
+#
+# * Version skew: when things are statically linked, it's perfectly ok to
+# make incompatible changes to the APIs defined in this directory, so long
+# as the current version in ../hacks/ is in sync. Much more care would
+# need to be taken with such things if dynamic libraries were involved,
+# to make sure that the major and minor versions of the library changed
+# at the appropriate time. This isn't too hard, but it's more work, and
+# yet another opportunity to screw up.
+#
+# * Runtime memory usage goes *up*. That's right, up! When a program
+# links in a dynamic library, the whole library is brought into the
+# address space, not just the files that are actually used. Normally,
+# this is ok, because if several programs are using (for example)
+# libX11.so, chances are that the savings outweighs the overhead. But
+# the nature of xscreensaver is that only one of the hacks ever runs at
+# a time -- so there would never be a second program using the utils/
+# dynamic library with which things could be shared.
+#
+# * Runtime speed decreases slightly, since dynamic code is marginally
+# slower. On modern machines, this probably doesn't make a perceptible
+# difference, however.
+#
+# So basically, I just don't think using libraries would be a win, and it would
+# definitely cause more of a maintenance and portability headache. However,
+# if someone else wants to do the work to make it be an option to configure,
+# and verifies that it works on several (more than three) different Unixes,
+# I'd be happy to take the patches.
+# -- jwz, 30-Jun-98
+#
+##############################################################################
+
+
@SET_MAKE@
.SUFFIXES:
.SUFFIXES: .c .o
projects / xscreensaver / blobdiff