edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Geoff McLane <ubuntu@geoffair.info>
To: Chuck Hallenbeck <chuckhallenbeck@gmail.com>,
	Karl Dahlke <eklhad@comcast.net>
Cc: edbrowse-dev@lists.the-brannons.com
Subject: Re: [Edbrowse-dev] Problem installing git version on debian sid
Date: Tue, 5 Dec 2017 19:57:10 +0100	[thread overview]
Message-ID: <0b962ba1-d483-1ff9-655f-364275099b28@geoffair.info> (raw)
In-Reply-To: <alpine.DEB.2.21.1712051211110.2124@debian.pulsar.com>

Hi all,

Sorry for the problems here, at least as far as HTML Tidy is concerned...

1. Yes, for some period recently, tidy.h was being installed in a 
sub-directory,
'tidy'... That is into /usr/include/tidy/, or /usr/local/include/tidy/...
However the FindTidy.cmake also accounted for this... But this has been
**fixed** in the latest 5.6

The cmake default is /usr/local/include unless you add the cmake option -
$ cmake ../.. -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Release

The second option is to ensure you are building the 'release' library. Some
cmake versions default to 'debug' unless this is specified...

But where ever it got installed to, you should be able to add -
$ export TIDY_ROOT=/path/to/tidy/install
when doing the edbrowse $ cmake .. [options]

Or even add it as a cmake option, -DTIDY_ROOT=/path/to/tidy/install

The CMakeFiles/FindTidy.cmake I supplied supports using this 'TIDY_ROOT'
define... either in environment or as an option...

This is so people like me, or Karl, and others, can build even later
versions of Tidy, and install them local to the build for testing edbrowse
with that version without disturbing the global release install of Tidy...

2. Yes, it takes time, too long in my book, for the latest tidy releases 
to show
up in distributions. And my searching showed Debian is still back at 5.2 
release.
There has been a 5.4 and now a 5.6 release since then...

And AFAIK Tidy has never been separated into 'tidy' and 'tidy-dev' 
packages, but
that would not stop some distributions doing that... in most cases the 
needed
headers and libraries were included in the quite small 'tidy' package...

3. Not sure I agree cpp/c++ are preprocessors packages... running either of
them with --help shows -c is a valid option, but maybe that is beside the
point...

As I first stated tidy is also a pure C package, and adding that to the
CMakeLists.txt, like project(tidy C) will tell cmake to not look for
a cpp/c++ compiler... and should allow latest 5.6 tidy to be built, and
installed... from the zip, or repo...

And likewise for edbrowse CMakeLists.txt, like project (edbrowse C),
if edbrowse also only uses C...

And I too can not understand why g++/cpp/c++ would be broken in
Debian sid... That is a real puzzle... but as stated not required
for tidy, nor edbrowse... just change the project (...) lines...

HTH, Geoff.


  reply	other threads:[~2017-12-05 18:55 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-04 15:48 Chuck Hallenbeck
2017-12-04 18:19 ` Geoff McLane
2017-12-04 19:48   ` Chuck Hallenbeck
2017-12-04 20:23     ` Geoff McLane
2017-12-04 23:42       ` Kevin Carhart
2017-12-05  0:47         ` Chuck Hallenbeck
2017-12-05 14:58           ` Chris Brannon
2017-12-05 16:36             ` Chuck Hallenbeck
2017-12-05 16:54               ` Karl Dahlke
2017-12-05 17:26                 ` Chuck Hallenbeck
2017-12-05 18:57                   ` Geoff McLane [this message]
2017-12-05 20:03                     ` Chuck Hallenbeck
2017-12-10  6:39                 ` [Edbrowse-dev] what is dispatchEvent and is it needed? Kevin Carhart
2017-12-10  6:48                   ` Karl Dahlke
2017-12-10  8:28                     ` Kevin Carhart
2017-12-05  1:01         ` [Edbrowse-dev] Problem installing git version on debian sid Chuck Hallenbeck
2017-12-04 20:12   ` Chuck Hallenbeck
2017-12-04 20:36     ` Karl Dahlke

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=0b962ba1-d483-1ff9-655f-364275099b28@geoffair.info \
    --to=ubuntu@geoffair.info \
    --cc=chuckhallenbeck@gmail.com \
    --cc=edbrowse-dev@lists.the-brannons.com \
    --cc=eklhad@comcast.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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