PATCH: 3.1.6 install without rebuild (Re: 3.0 DESTDIR)

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

This is a whole lot of verbiage ending in a very short patch.

On Oct 24, 10:30am, Clint Adams wrote:
} Subject: Re: 3.0 DESTDIR
}
} > (2) that recompile is a bug in the 3.1.6 build process which I think we
} > ought to fix whether or not DESTDIR is also available; and
} 
} Agreed.

The issue appears to be that the instructions for building zshpaths.h are
considered to be a module definition task (they're in zsh.mdd) rather than
a configuration task.  So they don't get pasted into a Makefile until the
"make -f Makemod" gets run, and hence are compile-time rather than config-
time substituted.  This is compounded by dependence on $(VERSION), which
is a make-time rather than config-time value as well.

However, I think the following patch will do the right things:  Before the
patch, the target zshpaths.h depends on FORCE, and then the rule avoids
touching the file if it hasn't changed.  The patch simply replaces FORCE
with a dependency on the .mk files that define the variables that become
part of the strings in zshpaths.h; so if you re-configure, or "cvs update"
to a newer version of the sources, zshpaths.h will get remade.

This means that "make MODDIR=/some/new/path fndir=/some/other/new/path"
does not recompile zsh, but "make ... install" still installs the modules
and functions in the new $(MODDIR) and $(fndir) locations.

I'm now considering backing out the $DESTDIR stuff, because with this patch
you can do this kind of thing (which works in 3.0.7 as well, by the way):

	configure --prefix='${INSTROOT}/usr/local'
	make
	make INSTROOT=/tmp/zshtest install

} However, I'm not sure why you would want to install files into
} /usr/local/stow that believe their functions/modules are going to be
} in /usr/local.

There's a GNU package called "stow" (based on something called "depot"
that originated at CMU).  It's a package-installation utility designed
for use in shared-filesystem environments.  Rather than copy the files
from the package directly into place the way an RPM or Debian package
does, it expects to find the packages in subdirectories of a directory
(usually also named "stow") whose *parent* directory is the equivalent
of the ${prefix}.  It constructs relative symlinks pointing into each
package's tree in the corresponding subdirs of the parent directory.

E.g., /usr/local/bin/zsh -> ../stow/zsh/bin/zsh after "stow zsh".

Thus the same "stow" directory can be NFS mounted on multiple machines,
and each of those machines can selectively install/uninstall packages
without consuming additional disk space.  This doesn't work for every
package, because some things get security indigestion if they find a
symlink in their execution path; but it's great for things like elisp
libraries and zsh functions that are architecture-independent and can
usually be updated independently of the interpreters that run them.

Here's the patch.

Index: Src/zsh.mdd
===================================================================
@@ -12,6 +12,8 @@
 prototypes.h hashtable.h ztype.h"
 
 :<<\Make
+@CONFIG_MK@
+
 signames.c: signames1.awk signames2.awk ../config.h @SIGNAL_H@
 	$(AWK) -f $(sdir)/signames1.awk @SIGNAL_H@ >sigtmp.c
 	$(CPP) sigtmp.c >sigtmp.out
@@ -28,7 +30,7 @@
 version.h: $(sdir_top)/Config/version.mk
 	echo '#define ZSH_VERSION "'$(VERSION)'"' > $@
 
-zshpaths.h: FORCE Makemod
+zshpaths.h: Makemod $(CONFIG_INCS)
 	@echo '#define MODULE_DIR "'$(MODDIR)'"' > zshpaths.h.tmp
 	@if test x$(fndir) != xno; then \
 	  echo '#define FPATH_DIR "'$(fndir)'"' >> zshpaths.h.tmp; \

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com