edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Adam Thompson <arthompson1990@gmail.com>
To: Geoff McLane <ubuntu@geoffair.info>
Cc: Dominique Martinet <asmadeus@codewreck.org>, edbrowse-dev@edbrowse.org
Subject: Re: [edbrowse-dev] documentation respecting install prefix in cmake
Date: Thu, 26 Dec 2019 18:43:23 +0000	[thread overview]
Message-ID: <20191226184323.GA4808@toaster> (raw)
In-Reply-To: <9247904b-0fb1-95c4-18cb-86f279dbfc98@geoffair.info>

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


> 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

> 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).


  reply	other threads:[~2019-12-26 18:43 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-25 13:36 Adam Thompson
2019-12-25 13:47 ` Dominique Martinet
2019-12-25 14:05   ` Adam Thompson
2019-12-25 16:29     ` Dominique Martinet
2019-12-25 17:42       ` Geoff McLane
2019-12-26 18:43         ` Adam Thompson [this message]
2019-12-26 20:31           ` Geoff McLane
2019-12-26 20:51             ` Dominique Martinet
2019-12-27 15:58               ` alf.siciliano
2019-12-27 20:26                 ` Geoff McLane
2020-01-16 20:28                   ` Adam Thompson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191226184323.GA4808@toaster \
    --to=arthompson1990@gmail.com \
    --cc=asmadeus@codewreck.org \
    --cc=edbrowse-dev@edbrowse.org \
    --cc=ubuntu@geoffair.info \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).