Re: [edbrowse-dev] documentation respecting install prefix in cmake

[Adam Thompson <arthompson1990@gmail.com>]

On Wed, Dec 25, 2019 at 06:42:48PM +0100, Geoff McLane wrote:
> Yes, I add my own CMAKE_INSTALL_PREFIX, to my $HOME directory...
> but see, in the output, if I do `$ sudo make install`,
>  `-- Installing: /usr/share/man/man1/edbrowse.1.gz`,
> so it seems, when CMake generates the `Unix Makfile` build, it has
> chosen other than my suggested install directory... for this `man`
> component... hmmm, why? That is NOT GOOD...
> 
> I can see, in that `UNIX Makfile` generation, it also gens
> a `cmake_install.cmake`, and runs cmake on that if given the `install`
> target...
> 
> And as pointed out, this is HARD CODED in the CMakeLists.txt as -
> if (UNIX)
>     FILE (GLOB UnixManFile "doc/man-edbrowse-debian.1")
>     set (UnixManDir "/usr/share/man/man1")
>     set (UnixDocDir "/usr/share/doc/edbrowse")
>     if (${CMAKE_SYSTEM_NAME} STREQUAL  "FreeBSD")
>     FILE (GLOB UnixManFile "doc/man-edbrowse-freebsd.1")
>         set (UnixManDir "/usr/local/man/man1")
>         set (UnixDocDir "/usr/local/share/doc/edbrowse")
>     endif()
> ...
> 
> Why so very HARD CODED defaults... That could be changed, modified,
> enhanced, etc...

To work with some very old or odd version of cmake?

> In the html-tidy tidy.1 generation/install, we have a MAN_INSTALL_DIR
> override option,
> but otherwise let cmake choose a default... which seems to default to -
> "${CMAKE_INSTALL_PREFIX}/share/man/man1"
> so, without that override, honors the users CMAKE_INSTALL_PREFIX... the
> default
> being "/usr/local"...
> 
> So I certainly think there could be some CMakeLists.txt patches here... will
> try to experiment... soonest... suggestions welcome...

Does pulling the entire setting work? Let cmake "do the right thing" and see
if that's sufficient? Or are there old versions of cmake we need to support
which require this?

> And Dominique, your patch does some of this, but still question why
> does edbrowse wants to define its own target UnixManDir... cmake has
> defaults
> like MAN_INSTALL_DIR...
> 
> Try setting CMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION and you will see
> what I mean... on install... no go...

Interesting, I didn't know that was a thing...  I clearly need to
familiarise myself with cmake at some stage fairly soon.

> As a developer, I need to be able to install-where-I-want,
> 100% ... to be able to check, inspect, try, test, ... even in
> /tmp/rubbish...
> and /NOTHING/ must be written /anywhere/ else... full stop...
> 
> So suggest the CMakeLists.txt patch go deeper... see html-tidy
> CMakeList.txt,
> where we use the xsltproc generated, big tidy.1, and install it...

Agreed.

> But Adam, do not fully understand your original comment -
> > that I specified the install prefix as /usr/local to avoid any issues with
> packages.
> 
> First, as I understand it, that /IS/ the cmake default, so no need to add
> it...

Not in build-me.sh.  That seems to default to home directory and, as I said,
I was unaware of cmake's defaults (ee previous comments about my almost
total lack of cmake knowledge).

> But what do you mean by `issues with packages`! What issues, with what
> packages, are
> you trying to avoid... maybe we can address those...

Not really.  Basically Debian packages Edbrowse.  Generally I try and avoid
having both installed at once (see library sadness from my previous emails)
but it's sometimes useful to be able to install the distro-packaged version
to check if something's gone wrong with my build.  In addition, since this
is my main browser, it's useful to be able to install the distro package in
the event that something's not working with my build.  In both cases it's
important that there's no overlapping files to avoid any issues with either
files being deleted or the package manager getting upset because of an
overwritten packaged file.

Generally dpkg seems to handle this stuff fairly well.  However, speaking
from my experience in my day job, it's almost always a good idea to keep
packaged and unpackaged software from playing with each other's installed
files.

> As an aside, it is certainly time to update the man-edbrowse-debian.1 line
> .TH edbrowse 1 2018-05-01 "edbrowse 3.7.3"
> 
> But that is off topic...

Yeah...  as you say a little off-topic but that can certainly be done fairly
easily.  Not sure if there're any changes which need to go in elsewhere in
the manpage (will have a look later today).

Cheers,
Adam.