>>>> "SJT" == Stephen J Turnbull writes:
SJT> If those are generated files, then it's not really our problem. We
SJT> can't know what site policy is about the ownership of those files.
SJT> root is plausible, but what about the group? We also don't know what
SJT> tools will be available. For example, gnu tar has an option to have
SJT> root also set the user of the files (ie, to root), but that's an
SJT> extension. Finally, XEmacs is used on systems where chown doesn't
SJT> even make sense and may not be available.
Yeah, that's all right. But some files[1] are installed correctly, and
some[2] -- aren't. Why not using the method, used for [1], for [2] also?
SJT> If you know of an app that is as portable cross-platform as XEmacs
SJT> that does that kind of thing, feel free to refer us to it (preferably,
SJT> give us a detailed summary of their system as well as the URL).
Well, last night I've rebuilt Gnus from CVS in such a manner. It's
installed correctly, while it's makefile is not complicated anyway.
--8<------------------------schnipp------------------------->8---
INSTALL = /usr/bin/install -c
INSTALL_DATA = ${INSTALL} -m 644
[...]
install-elc: clever
rm -f dgnushack.elc
$(SHELL) $(top_srcdir)/mkinstalldirs $(lispdir)
for p in *.elc; do \
echo " $(INSTALL_DATA) $$p $(lispdir)/$$p"; \
$(INSTALL_DATA) $$p $(lispdir)/$$p; \
done
--8<------------------------schnapp------------------------->8---
Here, on GNU/Linux, cp(1), as well as install(1) copies the file and
makes it owned by the current user, unless otherwise requested. The same
thing happens with xemacs binary and some of the files in
${prefix}/lib/xemacs-{version} (say, infos). But not with all.
I'm currently reading the top-level XEmacs Makefile. It seems, that it
uses tar to copy these files -- and it's not surprising, this
construction preserves the owner. I think, it would be nice, if it would
be changed to use install or cp. Or there're good reasons not to do so?
---Vas