edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
* [edbrowse-dev] documentation respecting install prefix in cmake
@ 2019-12-25 13:36 Adam Thompson
  2019-12-25 13:47 ` Dominique Martinet
  0 siblings, 1 reply; 11+ messages in thread
From: Adam Thompson @ 2019-12-25 13:36 UTC (permalink / raw)
  To: edbrowse-dev

Hi,

Appologies but my knowledge of cmake is...  limited to non-existant.  Is it
possible to make the documentation and manual location respect the install
prefix or do I just have to specify a different variable from
CMAKE_INSTALL_PREFIX to make this happen?

Currently the documentation seems to unconditionally install under
/usr/share/doc and the manpage under /usr/share/man/man1 dispite the fact
that I specified the install prefix as /usr/local to avoid any issues with
packages.

Cheers,
Adam.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [edbrowse-dev] documentation respecting install prefix in cmake
  2019-12-25 13:36 [edbrowse-dev] documentation respecting install prefix in cmake Adam Thompson
@ 2019-12-25 13:47 ` Dominique Martinet
  2019-12-25 14:05   ` Adam Thompson
  0 siblings, 1 reply; 11+ messages in thread
From: Dominique Martinet @ 2019-12-25 13:47 UTC (permalink / raw)
  To: Adam Thompson; +Cc: edbrowse-dev

Adam Thompson wrote on Wed, Dec 25, 2019:
> Currently the documentation seems to unconditionally install under
> /usr/share/doc and the manpage under /usr/share/man/man1 dispite the fact
> that I specified the install prefix as /usr/local to avoid any issues with
> packages.

That is more of a bug than documentation issue, it looks like UnixManDir
and UnixDocDir are hard-coded to /usr/share/... and do not use
${CMAKE_INSTALL_PREFIX}

Would probably need to add a check if it is set and use it then...

-- 
Dominique

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [edbrowse-dev] documentation respecting install prefix in cmake
  2019-12-25 13:47 ` Dominique Martinet
@ 2019-12-25 14:05   ` Adam Thompson
  2019-12-25 16:29     ` Dominique Martinet
  0 siblings, 1 reply; 11+ messages in thread
From: Adam Thompson @ 2019-12-25 14:05 UTC (permalink / raw)
  To: Dominique Martinet; +Cc: edbrowse-dev

On Wed, Dec 25, 2019 at 02:47:15PM +0100, Dominique Martinet wrote:
> Adam Thompson wrote on Wed, Dec 25, 2019:
> > Currently the documentation seems to unconditionally install under
> > /usr/share/doc and the manpage under /usr/share/man/man1 dispite the fact
> > that I specified the install prefix as /usr/local to avoid any issues with
> > packages.
> 
> That is more of a bug than documentation issue, it looks like UnixManDir
> and UnixDocDir are hard-coded to /usr/share/... and do not use
> ${CMAKE_INSTALL_PREFIX}
> 
> Would probably need to add a check if it is set and use it then...

Yes, sorry, I wasn't as clear as I should've been in the subject line.

I think we do something like this for install prefix.  I'd write the patch
but, as I said, my cmake knowledge is rather close to non-existent
unfortunately.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [edbrowse-dev] documentation respecting install prefix in cmake
  2019-12-25 14:05   ` Adam Thompson
@ 2019-12-25 16:29     ` Dominique Martinet
  2019-12-25 17:42       ` Geoff McLane
  0 siblings, 1 reply; 11+ messages in thread
From: Dominique Martinet @ 2019-12-25 16:29 UTC (permalink / raw)
  To: Adam Thompson; +Cc: edbrowse-dev

Adam Thompson wrote on Wed, Dec 25, 2019:
> I think we do something like this for install prefix.  I'd write the patch
> but, as I said, my cmake knowledge is rather close to non-existent
> unfortunately.

I don't know much either, but it's always possible to test.

It looks like CMAKE_INSTALL_PREFIX is always defined (at least on my
version of cmake, 3.14.5), so I have submitted a patch in my cmake
branch https://github.com/martinetd/edbrowse/tree/cmake

Someone with an older version might want to check, but their
documentation does not say anything about it having changed recently so
it probably is ok:
https://cmake.org/cmake/help/latest/variable/CMAKE_INSTALL_PREFIX.html

They do talk about GNUInstallDirs though which has MANDIR and DOCDIR
variables we could use. That might be a better fix...

-- 
Dominique

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [edbrowse-dev] documentation respecting install prefix in cmake
  2019-12-25 16:29     ` Dominique Martinet
@ 2019-12-25 17:42       ` Geoff McLane
  2019-12-26 18:43         ` Adam Thompson
  0 siblings, 1 reply; 11+ messages in thread
From: Geoff McLane @ 2019-12-25 17:42 UTC (permalink / raw)
  To: Dominique Martinet, Adam Thompson; +Cc: edbrowse-dev

Hi Adam,

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

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

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

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

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

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

HTH,

Regards, Geoff.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [edbrowse-dev] documentation respecting install prefix in cmake
  2019-12-25 17:42       ` Geoff McLane
@ 2019-12-26 18:43         ` Adam Thompson
  2019-12-26 20:31           ` Geoff McLane
  0 siblings, 1 reply; 11+ messages in thread
From: Adam Thompson @ 2019-12-26 18:43 UTC (permalink / raw)
  To: Geoff McLane; +Cc: Dominique Martinet, edbrowse-dev

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.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [edbrowse-dev] documentation respecting install prefix in cmake
  2019-12-26 18:43         ` Adam Thompson
@ 2019-12-26 20:31           ` Geoff McLane
  2019-12-26 20:51             ` Dominique Martinet
  0 siblings, 1 reply; 11+ messages in thread
From: Geoff McLane @ 2019-12-26 20:31 UTC (permalink / raw)
  To: Adam Thompson; +Cc: Dominique Martinet, edbrowse-dev

Hi Dominique, Adam,

What was I thinking... I am out of my depth... me, offer UNIX 
suggestion... ha, ha,...

But I do use cmake all-the-time, as my preferred cross-os build system 
generator...

And Adam, certainly agree with "it's almost always a good idea to keep
packaged and unpackaged software from playing with each other's installed
files."...

In a way that's why my build-me.sh is set to /NOT/ touch a dpkg install...

I started to look around at various other projects I can compile with 
CMake...
find a lot of sometimes confusing, even contradictory... information...
and all that I find do often define their own man or doc install 
directories...
but generally each make it dependent on the root CMAKE_INSTALL_PREFIX...

So Dominique, it seems the fix you have is good... will get to testing 
that...

But other questions popped up... like...

why do we have 2 slightly different UnixManFile... debian vs freebsd...
are the man app implementations /SO/ different... in a quick review, seems
they could be one...

And they could use like @EDB_VERSION@, @VER_DATE@, etc... even say a
@DOC_INSTALL@, for the usersguide.html pointer... etc... etc...

It seems the cmake default CMAKE_INSTALL_PREFIX of "/usr/local" is
generally agreed as the /ROOT/...

So others components are "/ROOT/bin, lib, include"

And then the man being "/ROOT/share/man/man1"...

But it looks like some distros prefer "/ROOT/man/man1", which
would also be ok in my Ubuntu debian based linux, in that there is
a link "man -> share/man" ... must look in my Raspian RPI...

Then the docs to "/ROOT/share/doc/<project>"...

But like I say, who am I to suggest anything in unix ;=))

Must have been too full of the Christmas cheer...

As state, your patch looks like a good start... sorry for the noise...

Regards, Geoff.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [edbrowse-dev] documentation respecting install prefix in cmake
  2019-12-26 20:31           ` Geoff McLane
@ 2019-12-26 20:51             ` Dominique Martinet
  2019-12-27 15:58               ` alf.siciliano
  0 siblings, 1 reply; 11+ messages in thread
From: Dominique Martinet @ 2019-12-26 20:51 UTC (permalink / raw)
  To: Geoff McLane; +Cc: Adam Thompson, edbrowse-dev, Alfonso Siciliano

Hi Geoff,

Geoff McLane wrote on Thu, Dec 26, 2019:5B
> I started to look around at various other projects I can compile with CMake...
> find a lot of sometimes confusing, even contradictory... information...

That seem to be a recurring problem with build systems as new versions
come out...
If the MAN_INSTALL_DIR and co have been defined for enough versions I
think it is better, but it does not look like a default variable to me,
something to do with KDE install dirs perhaps?
At this point I think the ideal solution would be using GNUInstallDirs's
MANDIR and DOCDIR as I suggested earlier, but the safest would be as
little change as possible like I had done.


> why do we have 2 slightly different UnixManFile... debian vs freebsd...
> are the man app implementations /SO/ different... in a quick review, seems
> they could be one...

That is a good question, it looks like Alfonso Siciliano preferred
adding a freebsd man page to using the debian one from the git log?
I have added him in exlpicit CCs to this mail.

> And they could use like @EDB_VERSION@, @VER_DATE@, etc... even say a
> @DOC_INSTALL@, for the usersguide.html pointer... etc... etc...
>
> It seems the cmake default CMAKE_INSTALL_PREFIX of "/usr/local" is
> generally agreed as the /ROOT/...
> 
> So others components are "/ROOT/bin, lib, include"
> 
> And then the man being "/ROOT/share/man/man1"...
> 
> But it looks like some distros prefer "/ROOT/man/man1", which
> would also be ok in my Ubuntu debian based linux, in that there is
> a link "man -> share/man" ... must look in my Raspian RPI...
> 
> Then the docs to "/ROOT/share/doc/<project>"...

Ah, I had missed that FreeBSD wanted the man page in /usr/local/man
(without /share/) in our CMakeLists.
Looking at the FreeBSD release notes[1] that are a bit difficult to
read, the man pages should go either to /usr/share/man if the prefix is
/usr but if it is /usr/local then it should go directly to
/usr/local/man for some reason... Odd... But that means my fix is
incorrect.
I just checked and the MANDIR variable from GNUInstallDirs has the
correct exception for all BSDs, so I will update my patch to use that
instead.

[1] https://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&sektion=0&manpath=FreeBSD+6.1-RELEASE&format=html

> But like I say, who am I to suggest anything in unix ;=))
> 
> Must have been too full of the Christmas cheer...

Enjoy the remaining holidays as well :)

-- 
Dominique

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [edbrowse-dev] documentation respecting install prefix in cmake
  2019-12-26 20:51             ` Dominique Martinet
@ 2019-12-27 15:58               ` alf.siciliano
  2019-12-27 20:26                 ` Geoff McLane
  0 siblings, 1 reply; 11+ messages in thread
From: alf.siciliano @ 2019-12-27 15:58 UTC (permalink / raw)
  To: edbrowse-dev; +Cc: Geoff McLane, Adam Thompson, Dominique Martinet

Hi All and Enjoy the Holidays!

On Thu, 26 Dec 2019 21:51:00 +0100
Dominique Martinet <asmadeus@codewreck.org> wrote:

> > why do we have 2 slightly different UnixManFile... debian vs freebsd...
> > are the man app implementations /SO/ different... in a quick review, seems
> > they could be one...
> 
> That is a good question, it looks like Alfonso Siciliano preferred
> adding a freebsd man page to using the debian one from the git log?
> I have added him in exlpicit CCs to this mail.

I added the man-edbrowse-freebsd.1 some year ago because I was bored 
to patch the manual every time the FreeBSD port/package was updated,
now man-edbrowse-freebsd.1 is also used by OpenBSD:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/www/edbrowse/patches/patch-CMakeLists_txt?rev=1.2

I honestly forgot the problem. Anyway, actually the manuals are different info
so I think we could try to join them in just one "edbrowse.1",
obviously I have no problem about copyright and license.
 
> > And they could use like @EDB_VERSION@, @VER_DATE@, etc... even say a
> > @DOC_INSTALL@, for the usersguide.html pointer... etc... etc...
> >
> > It seems the cmake default CMAKE_INSTALL_PREFIX of "/usr/local" is
> > generally agreed as the /ROOT/...
> > 
> > So others components are "/ROOT/bin, lib, include"
> > 
> > And then the man being "/ROOT/share/man/man1"...
> > 
> > But it looks like some distros prefer "/ROOT/man/man1", which
> > would also be ok in my Ubuntu debian based linux, in that there is
> > a link "man -> share/man" ... must look in my Raspian RPI...
> > 
> > Then the docs to "/ROOT/share/doc/<project>"...
> 
> Ah, I had missed that FreeBSD wanted the man page in /usr/local/man
> (without /share/) in our CMakeLists.
> Looking at the FreeBSD release notes[1] that are a bit difficult to
> read, the man pages should go either to /usr/share/man if the prefix is
> /usr but if it is /usr/local then it should go directly to
> /usr/local/man for some reason... Odd... But that means my fix is
> incorrect.
> I just checked and the MANDIR variable from GNUInstallDirs has the
> correct exception for all BSDs, so I will update my patch to use that
> instead.
> 
> [1] https://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&sektion=0&manpath=FreeBSD+6.1-RELEASE&format=html
> 

I read your patch:
https://github.com/martinetd/edbrowse/commit/d661da5d7e9b448778a32a3bf3c5c4486c9010e7

particularly I noted:
set (UnixManDir "${CMAKE_INSTALL_PREFIX}/share/man/man1")

the manual should be in /usr/local/man/man1 not in */share/*

I tried GNUInstallDirs, it is OK for FreeBSD:

include(GNUInstallDirs)
if (UNIX)
        FILE (GLOB UnixManFile "doc/man-edbrowse-debian.1")
        set (UnixManDir "${CMAKE_INSTALL_FULL_MANDIR}/man1")
        set (UnixDocDir "${CMAKE_INSTALL_FULL_DOCDIR}")
        if (${CMAKE_SYSTEM_NAME} STREQUAL  "FreeBSD")
                FILE (GLOB UnixManFile "doc/man-edbrowse-freebsd.1")
        endif ()
endif ()

UnixManDir = /usr/local/man/man1
UnixDocDir = /usr/local/share/doc/edbrowse

Anyway, if FreeBSD is a problem in that "cmake context" you could ignore it,
I' ll handle it via the FreeBSD port/package Makefile.


Alfonso

--- 
alf.siciliano@gmail.com <alf.siciliano@gmail.com>

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [edbrowse-dev] documentation respecting install prefix in cmake
  2019-12-27 15:58               ` alf.siciliano
@ 2019-12-27 20:26                 ` Geoff McLane
  2020-01-16 20:28                   ` Adam Thompson
  0 siblings, 1 reply; 11+ messages in thread
From: Geoff McLane @ 2019-12-27 20:26 UTC (permalink / raw)
  To: alf.siciliano, edbrowse-dev; +Cc: Adam Thompson, Dominique Martinet

Hi Dominique, Adam, Alfonso,

Thanks for the holiday wishes... you all, enjoy...

I might not know unix very well, but trying to continue to learn...
but I do know cmake quite well, for quite a long time... over many
cmake versions, back before say 2.6.4 of circa 2009...

And I reminded myself of why even -
     set (UnixManDir "${CMAKE_INSTALL_PREFIX}/share/man/man1")
     set (UnixDocDir "${CMAKE_INSTALL_PREFIX}/share/doc/edbrowse")
is wrong...

Not quite as wrong as -
     set (UnixManDir "/usr/share/man/man1")
     set (UnixDocDir "/usr/share/doc/edbrowse")
but still wrong, in principal...

The CMake principal:

If the path, in the cmake install line, after the keyword DESTINATION,
begins with a forward slash, /, then cmake will treat it as an
absolute path...

And thus when generating the cmake_install.cmake will
add a warning/error, if asked with 
-DCMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION...
about using an absolute path... so devs can check before installs...

This condition should be avoided, even if your patch does generate an 
acceptable
absolute path...

This should be a relative path, to the CMAKE_INSTALL_PREFIX, like
     set (UnixManDir "share/man/man1")
     set (UnixDocDir "share/doc/edbrowse")

And yes, that relative path can be adjusted for specific distros... like 
add/sub
the 'share' part, if need be, but always remain relative to the /ROOT/...

Then the ugly cmake warning/error is /not/ generated... and all install
files goto the CMAKE_INSTALL_PREFIX... what ever the distro default,
or user choice, is... and nowhere else...

And now begin to think even html tidy's use of MAN_INSTALL_DIR is
also not quite right... but seems to work, without the absolute
message... but now do /NOT/ suggest it...

And yes, this is all tied up to the auto-make tools, which have
ENV vars, like MANDIR, DOCDIR, ..., which can still be used...
with cmake...

Which leads to the GNUInstallDirs, with monstrosities like
CMAKE_INSTALL_MANDIR and CMAKE_INSTALL_DOCDIR... and/or, as
Alfonso suggests, maybe CMAKE_INSTALL_FULL_MANDIR/DOCDIR... which
again seems best to avoid...

So I think edbrowse CMakeLists.txt should stick to using a
simple relative path only... for maximum compatibility...

Anyway, that's my added 2 cents... ;=))

Regards, Geoff.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [edbrowse-dev] documentation respecting install prefix in cmake
  2019-12-27 20:26                 ` Geoff McLane
@ 2020-01-16 20:28                   ` Adam Thompson
  0 siblings, 0 replies; 11+ messages in thread
From: Adam Thompson @ 2020-01-16 20:28 UTC (permalink / raw)
  To: Geoff McLane; +Cc: alf.siciliano, edbrowse-dev, Dominique Martinet

Been a while, where did we get to on this? I don't see any update in the
repo.  Did we ever take the patch or did someone (who?) need to do something?

On Fri, Dec 27, 2019 at 09:26:48PM +0100, Geoff McLane wrote:
> Hi Dominique, Adam, Alfonso,
> 
> Thanks for the holiday wishes... you all, enjoy...
> 
> I might not know unix very well, but trying to continue to learn...
> but I do know cmake quite well, for quite a long time... over many
> cmake versions, back before say 2.6.4 of circa 2009...
> 
> And I reminded myself of why even -
>     set (UnixManDir "${CMAKE_INSTALL_PREFIX}/share/man/man1")
>     set (UnixDocDir "${CMAKE_INSTALL_PREFIX}/share/doc/edbrowse")
> is wrong...
> 
> Not quite as wrong as -
>     set (UnixManDir "/usr/share/man/man1")
>     set (UnixDocDir "/usr/share/doc/edbrowse")
> but still wrong, in principal...
> 
> The CMake principal:
> 
> If the path, in the cmake install line, after the keyword DESTINATION,
> begins with a forward slash, /, then cmake will treat it as an
> absolute path...
> 
> And thus when generating the cmake_install.cmake will
> add a warning/error, if asked with
> -DCMAKE_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION...
> about using an absolute path... so devs can check before installs...
> 
> This condition should be avoided, even if your patch does generate an
> acceptable
> absolute path...
> 
> This should be a relative path, to the CMAKE_INSTALL_PREFIX, like
>     set (UnixManDir "share/man/man1")
>     set (UnixDocDir "share/doc/edbrowse")
> 
> And yes, that relative path can be adjusted for specific distros... like
> add/sub
> the 'share' part, if need be, but always remain relative to the /ROOT/...
> 
> Then the ugly cmake warning/error is /not/ generated... and all install
> files goto the CMAKE_INSTALL_PREFIX... what ever the distro default,
> or user choice, is... and nowhere else...
> 
> And now begin to think even html tidy's use of MAN_INSTALL_DIR is
> also not quite right... but seems to work, without the absolute
> message... but now do /NOT/ suggest it...
> 
> And yes, this is all tied up to the auto-make tools, which have
> ENV vars, like MANDIR, DOCDIR, ..., which can still be used...
> with cmake...
> 
> Which leads to the GNUInstallDirs, with monstrosities like
> CMAKE_INSTALL_MANDIR and CMAKE_INSTALL_DOCDIR... and/or, as
> Alfonso suggests, maybe CMAKE_INSTALL_FULL_MANDIR/DOCDIR... which
> again seems best to avoid...
> 
> So I think edbrowse CMakeLists.txt should stick to using a
> simple relative path only... for maximum compatibility...
> 
> Anyway, that's my added 2 cents... ;=))
> 
> Regards, Geoff.
> 

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2020-01-16 20:28 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-25 13:36 [edbrowse-dev] documentation respecting install prefix in cmake 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
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

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