Some paths in config/Paths.mk.in are used nowhere, so remove them.
Signed-off-by: Juergen Gross <jgross@suse.com>
---
config/Paths.mk.in | 5 -----
1 file changed, 5 deletions(-)
diff --git a/config/Paths.mk.in b/config/Paths.mk.in
index bc42748b7a..668545be2f 100644
--- a/config/Paths.mk.in
+++ b/config/Paths.mk.in
@@ -20,10 +20,7 @@ libexecdir := @libexecdir@
datarootdir := @datarootdir@
mandir := @mandir@
docdir := @docdir@
-dvidir := @dvidir@
htmldir := @htmldir@
-pdfdir := @pdfdir@
-psdir := @psdir@
includedir := @includedir@
localstatedir := @localstatedir@
sysconfdir := @sysconfdir@
@@ -34,8 +31,6 @@ LIBEXEC_LIB := @LIBEXEC_LIB@
LIBEXEC_INC := @LIBEXEC_INC@
SHAREDIR := @SHAREDIR@
-MAN1DIR := $(mandir)/man1
-MAN8DIR := $(mandir)/man8
XEN_RUN_DIR := @XEN_RUN_DIR@
XEN_LOG_DIR := @XEN_LOG_DIR@
--
2.51.0On 11.11.2025 17:19, Juergen Gross wrote: > --- a/config/Paths.mk.in > +++ b/config/Paths.mk.in > @@ -20,10 +20,7 @@ libexecdir := @libexecdir@ > datarootdir := @datarootdir@ > mandir := @mandir@ > docdir := @docdir@ > -dvidir := @dvidir@ > htmldir := @htmldir@ > -pdfdir := @pdfdir@ Question is whether we're mistakenly not respecting in particular this one, for the *.pdf we create. For all the others I agree there's no (present or potential) use. I notice though that docs/Makefile cleans e.g. *.dvi nevertheless. Jan > -psdir := @psdir@ > includedir := @includedir@ > localstatedir := @localstatedir@ > sysconfdir := @sysconfdir@ > @@ -34,8 +31,6 @@ LIBEXEC_LIB := @LIBEXEC_LIB@ > LIBEXEC_INC := @LIBEXEC_INC@ > > SHAREDIR := @SHAREDIR@ > -MAN1DIR := $(mandir)/man1 > -MAN8DIR := $(mandir)/man8 > > XEN_RUN_DIR := @XEN_RUN_DIR@ > XEN_LOG_DIR := @XEN_LOG_DIR@
On 13.11.25 17:59, Jan Beulich wrote: > On 11.11.2025 17:19, Juergen Gross wrote: >> --- a/config/Paths.mk.in >> +++ b/config/Paths.mk.in >> @@ -20,10 +20,7 @@ libexecdir := @libexecdir@ >> datarootdir := @datarootdir@ >> mandir := @mandir@ >> docdir := @docdir@ >> -dvidir := @dvidir@ >> htmldir := @htmldir@ >> -pdfdir := @pdfdir@ > > Question is whether we're mistakenly not respecting in particular this one, > for the *.pdf we create. We could as well use docdir for PDFs, right? In case we really want pdfdir later we can easily re-add it. Juergen
On 13.11.2025 17:59, Jan Beulich wrote: > On 11.11.2025 17:19, Juergen Gross wrote: >> --- a/config/Paths.mk.in >> +++ b/config/Paths.mk.in >> @@ -20,10 +20,7 @@ libexecdir := @libexecdir@ >> datarootdir := @datarootdir@ >> mandir := @mandir@ >> docdir := @docdir@ >> -dvidir := @dvidir@ >> htmldir := @htmldir@ >> -pdfdir := @pdfdir@ > > Question is whether we're mistakenly not respecting in particular this one, > for the *.pdf we create. For all the others I agree there's no (present or > potential) use. I notice though that docs/Makefile cleans e.g. *.dvi > nevertheless. Actually, I can't spot a use of htmldir either, when likely we should respect that one, too. Jan
On 13/11/2025 5:02 pm, Jan Beulich wrote:
> On 13.11.2025 17:59, Jan Beulich wrote:
>> On 11.11.2025 17:19, Juergen Gross wrote:
>>> --- a/config/Paths.mk.in
>>> +++ b/config/Paths.mk.in
>>> @@ -20,10 +20,7 @@ libexecdir := @libexecdir@
>>> datarootdir := @datarootdir@
>>> mandir := @mandir@
>>> docdir := @docdir@
>>> -dvidir := @dvidir@
>>> htmldir := @htmldir@
>>> -pdfdir := @pdfdir@
>> Question is whether we're mistakenly not respecting in particular this one,
>> for the *.pdf we create. For all the others I agree there's no (present or
>> potential) use. I notice though that docs/Makefile cleans e.g. *.dvi
>> nevertheless.
> Actually, I can't spot a use of htmldir either, when likely we should respect
> that one, too.
Besides the manpages, nothing generated in docs/ is really fit to
package for end users. There's no coherent structure, some of it is
straight braindumps from developers.
docdir is only used by the {un,}install-html targets (opencoding
htmldir), and the rm in the install target is further evidence to the
unsuitability of what's there.
I'd go so far as to suggest we should drop install-html, except that it
would break the generation of https://xenbits.xen.org/docs/unstable/
~Andrew
On 13.11.25 20:58, Andrew Cooper wrote:
> On 13/11/2025 5:02 pm, Jan Beulich wrote:
>> On 13.11.2025 17:59, Jan Beulich wrote:
>>> On 11.11.2025 17:19, Juergen Gross wrote:
>>>> --- a/config/Paths.mk.in
>>>> +++ b/config/Paths.mk.in
>>>> @@ -20,10 +20,7 @@ libexecdir := @libexecdir@
>>>> datarootdir := @datarootdir@
>>>> mandir := @mandir@
>>>> docdir := @docdir@
>>>> -dvidir := @dvidir@
>>>> htmldir := @htmldir@
>>>> -pdfdir := @pdfdir@
>>> Question is whether we're mistakenly not respecting in particular this one,
>>> for the *.pdf we create. For all the others I agree there's no (present or
>>> potential) use. I notice though that docs/Makefile cleans e.g. *.dvi
>>> nevertheless.
>> Actually, I can't spot a use of htmldir either, when likely we should respect
>> that one, too.
>
> Besides the manpages, nothing generated in docs/ is really fit to
> package for end users. There's no coherent structure, some of it is
> straight braindumps from developers.
>
> docdir is only used by the {un,}install-html targets (opencoding
> htmldir), and the rm in the install target is further evidence to the
> unsuitability of what's there.
>
> I'd go so far as to suggest we should drop install-html, except that it
> would break the generation of https://xenbits.xen.org/docs/unstable/
I think I'll leave further cleanup for another patch.
As you said, docdir is being used right now and htmldir could be used in
case the open coding via docdir is being cleaned up.
Juergen
© 2016 - 2025 Red Hat, Inc.