From: Adam Thompson <arthompson1990@gmail.com>
To: Geoff McLane <ubuntu@geoffair.info>
Cc: Dominique Martinet <asmadeus@codewreck.org>,
"alf.siciliano@gmail.com" <alf.siciliano@gmail.com>,
edbrowse-dev@edbrowse.org
Subject: Re: [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian
Date: Sun, 8 Dec 2019 13:22:47 +0000 [thread overview]
Message-ID: <20191208132247.GE194728@toaster> (raw)
In-Reply-To: <b756b325-34ce-6fb5-6af0-ce6aeb3cd74c@geoffair.info>
On Sun, Dec 08, 2019 at 03:29:04AM +0100, Geoff McLane wrote:
> So sorry for the role 'libTidy' plays in this...
>
> Since it was introduced, circa 2017, the option 'TidyStyleTags' is a
> boolean... ie use 'tidyOptSetBool'... No change is allowed... even if it
> works... no ifdef whatever... since commit [1]... full stop...
That's what I thought which is why this was so odd.
> When linking, the installed version of tidy, through 'FindTidy.cmake', when
> found, and used, it is of paramount importance, that the installed
> 'lbtidy-dev', namely the headers, are of the /SAME/ version...
>
> That is the tidy.h, which includes tidyenum.h, are of the /SAME/ version as
> the shared library found... not very easy to determine...
>
> Else there will be 'assert' problems in the non-release build, and unknown,
> untold, unseen, problems otherwise...
Yes... I had a closer look at the state of the system. Turns out that,
whereas the library versions appeared to be correct in terms of linking (tidy
5 for both) it was somehow finding headers from a different version of tidy5
compiled from the git repo... Sorry for not noticing the old headers
(thought I'd deleted those). I wonder if there's a version/release date in
the headers anywhere which can be used, when debugging such issues, to tell
such things?
To be specific: on debian the tidy5 headers live in /usr/include/tidy
whereas the standard install location for compiled tidy5 from git would
appear to be /usr/local/include.
As another question, why is TidyBodyOnly an option which takes a bool as an
argument but tidySetOptInt is used to set it?
Cheers,
Adam.
PS: Appologies again for not noticing the system was in an... odd... state.
next prev parent reply other threads:[~2019-12-08 13:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-07 17:15 Adam Thompson
2019-12-07 18:43 ` Dominique Martinet
2019-12-07 19:01 ` Alfonso S. Siciliano
2019-12-07 19:34 ` Dominique Martinet
2019-12-07 19:49 ` Adam Thompson
2019-12-07 21:45 ` alf.siciliano
2019-12-07 22:16 ` Dominique Martinet
2019-12-08 2:29 ` Geoff McLane
2019-12-08 3:56 ` Karl Dahlke
2019-12-08 8:08 ` Alfonso Sabato Siciliano
2019-12-08 8:07 ` Dominique Martinet
2019-12-08 13:22 ` Adam Thompson [this message]
2019-12-08 21:22 ` Geoff McLane
2019-12-07 19:44 ` 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:
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=20191208132247.GE194728@toaster \
--to=arthompson1990@gmail.com \
--cc=alf.siciliano@gmail.com \
--cc=asmadeus@codewreck.org \
--cc=edbrowse-dev@edbrowse.org \
--cc=ubuntu@geoffair.info \
/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).