[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #51003] "test-groff" can't find doc-macros in the "tmac/mdoc" direc
From: |
Ingo Schwarze |
Subject: |
[bug #51003] "test-groff" can't find doc-macros in the "tmac/mdoc" directory |
Date: |
Sat, 13 May 2017 11:10:50 -0400 (EDT) |
User-agent: |
Mozilla/5.0 (X11; OpenBSD amd64; rv:53.0) Gecko/20100101 Firefox/53.0 |
Follow-up Comment #4, bug #51003 (project groff):
> It could (to whom?, and why?. Is it solvable?).
To developers trying to maintain groff, and to users trying to install it from
source, trying to port it to new platforms, and trying to debug problems they
encounter. Because build systems are already complicated without adding
needless complication.
It is not completely solvable. A build system of software as complex as groff
will always remain complicated. The best we can do is keep it as simple as
possible.
It is *NOT* the job of a build system to try and create a half-working
pseudo-installation inside the source directory. The job of the source tree
is to contain one copy of each required source file in a place that is logical
for development (and not as an installation location). The job of the build
system is to read the source files and create one copy of each required
autogenerated file, in whichever location in the build directory is simplest.
The job of the install target is to copy these autogenerated files (and maybe
some source files) to as many installation locations as required for the
software to work. Mixing up these jobs is a recipe for confusion and bugs.
> Creating the missing directory and the links in the
> git-repository was for me the simplest solution.
It doesn't even work reliably. If you follow the advice in INSTALL.REPO to
create a separate build directory, it will fail.
> Another is to let the Makefile create the directory and links.
Yeah, somehere is tmac/tmac.am or somewhere similar, that might work. But
it's likely to remain fragile, and it will definitely add additional
complexity to the build system. We should strive to *simplify* the build
system, not make it even more complicated than it already is.
Really, hacking around in order to make test-groff better is not worth making
maintenance harder and increasing the risk of bugs in the released software.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?51003>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/