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