>>>> "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