From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 440BA78835 for ; Sun, 8 Dec 2019 13:23:01 -0800 (PST) Received: by mail-wr1-x441.google.com with SMTP id j42so13773243wrj.12 for ; Sun, 08 Dec 2019 13:23:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=geoffair-info.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=kpQdytoj4R+9C+7dAJcLoyVJL6uZWWis9hYlJH7tAaE=; b=m94dSJP3NotgUhCE8P1WDNDR/mgwIw4GOidzdbYfRhzUu3srLZ1pKL6WYbeCoPF0aK +HpPmupDMbwcr5BnUn1SpqXsoMA2D6ClYJ5ynqWT145nhXIfWfyvnqBCOQqX7tjScdx2 MXakCHXIAbvPlxCMu15HiQnH+svRpMbQ6Pm1I5yGpI9zZDN+f+oCmplv1DtoRq2NQ2g0 8zBg9WYKVaL6Yv8TcupPN3xdZ2dPU1HbF3hYbpsMHwPlwWDjruaFr11k2Jt6hpaHVejK DrsC72wpQLQ92PRJt2MNfh0j35C0uIpdrcCyuIQ6Hi/bxQVQBH/dobIXSCVzjMcN8+Yn FNpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=kpQdytoj4R+9C+7dAJcLoyVJL6uZWWis9hYlJH7tAaE=; b=Br0dqrNarl03OzcgQK06hBnToiYmek1cMATTG8REKqg72pwpbTWLtA9Fc4tl0826lf XC9AbOjb1IitnveM/chFIUj9QKCIc4GudTd1s9r4HmYfpzh6AkNe1O2L2vYwg0T91xRg ijZTaMPOG/S3uqyw7vI+/l7OoKAPv5ZWZqDuQtGEOWrUmBpoHVJZ6LXTOSMWs/Fqb5Sw wOXT8kX2mEM+gLH/GPMppLXlwUbuCgdAtfbF1F01VHuoLmy4MdnIap469vpm+OO8FPOQ aVxfliucYVVLSCG2bYJjO5c2SBnYk53iLHF2DsLV0oKJvODE0s56x0NhVr136cyOsGjG 4Geg== X-Gm-Message-State: APjAAAUK1SV770LVzLqeJy47h02v3YE0nHf6p3Lsgt3nz7VIS5SyV5dA stXQafVxERKiHVrQnV0k5DAttWHlzJQ= X-Google-Smtp-Source: APXvYqy/pVQWpFWi7PRJER7iz2aaGQiDt8wAMEaYwUcJ5wZ0ppuahTyzXyD76GcPd8olsHJIrEk0xQ== X-Received: by 2002:adf:fe07:: with SMTP id n7mr19659756wrr.286.1575840179033; Sun, 08 Dec 2019 13:22:59 -0800 (PST) Received: from ?IPv6:2a01:cb04:4ba:c500:810c:6f99:4d04:3a6b? (2a01cb0404bac500810c6f994d043a6b.ipv6.abo.wanadoo.fr. [2a01:cb04:4ba:c500:810c:6f99:4d04:3a6b]) by smtp.googlemail.com with ESMTPSA id u69sm11965898wmu.39.2019.12.08.13.22.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 08 Dec 2019 13:22:58 -0800 (PST) Subject: Re: [edbrowse-dev] tidySetOptBool vs tidySetOptInt on debian To: Adam Thompson Cc: Dominique Martinet , "alf.siciliano@gmail.com" , edbrowse-dev@edbrowse.org References: <20191207171534.GA194728@toaster> <20191207184354.GA5418@nautica> <20191207200147.ca1a7b961f790d11feab8fe7@gmail.com> <20191207193433.GA15586@nautica> <20191207194928.GD194728@toaster> <20191207224543.ec830db69d404376505a33ea@gmail.com> <20191207221625.GA12745@nautica> <20191208132247.GE194728@toaster> From: Geoff McLane Message-ID: <33e82200-8dcf-1fac-671f-688e47b0eed2@geoffair.info> Date: Sun, 8 Dec 2019 22:22:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 X-BeenThere: edbrowse-dev@edbrowse.org List-Id: Edbrowse Development List MIME-Version: 1.0 In-Reply-To: <20191208132247.GE194728@toaster> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Hi, A few things here - 1: Windows compile - the change to using 'pthread_equal' fixed this... thanks... 2: The 'show-body-only', aka 'TidyBodyOnly', is /not/ strictly a boolean otpion, but a special, tidy defined, so called 'autobool' option. This is a tri-state option, which is kept/maintained internally as in integer, 0 (no) TidyNoState, 1 (yes) TidyYesState, 2 (auto) TidyAutoState, so uses 'tidyOptSetInt' to set it... 3: Yes, "Writing software for various systems and platforms is challenging, ...", but not insurmountable... Maybe 'alarmed' by the 'findTidy.cmake' change, is a bad choice of words... for a distro which changed the /name/ of the tidy shared library, maybe very necessary, regretfully... there seems no other solution... if the name is changed... But in the specific as given case, /ONLY/ by shear chance, did it work... By default cmake will search in /usr/include, and I think /usr/local/include, in most cases, but seemingly not always, when searching for the 'tidy.h' header. And the current 'FindTidy.cmake' also allows, if not found in the suffix 'include', to search 'include/tidy' as well... but only if /NOT/ found in 'include'... the order of 'PATH_SUFFIXES' matters... Again, if there was no other conflicting 'libtidy-dev' installed, then this would find /usr/local/include/tidy/tidy.h and libtidy.so => libtidy.0.99 (www/tidy-lib port), and all would be fine... except the current eb/html-tidy.c code would fail to compile, since 'TidyStyleTags' would /NOT/ be found in those old headers... Ideally, when a later 'libtidy-dev' was installed, with /NO/ name change, it would overwrite the libtidy.so link... with something like 'libtidy.so.5.7.28'... then the later 'tidy.h', now in just 'include', would match the libtidy found... and all would again be fine... would compile, link, and run normally... Even if the residual, OLD 'include/tidy/tidy.h', and 'libtidy.so.0.99.0' etc etc were /NOT/ removed... And, unfortunately, there is no version/date in the headers themselves, so identifying and deleting the /OLD/ can be a challenge... of course, $ grep TidyStyleTags tidyenum.h, will tell you if it is pre-2017, or not... I can not speak for what distro maintainer feel they must do... this type of name change has been discussed, at length, in tidy issues, especially for debian... and you will see I strongly felt there should be no name change... this is just the evolution of 'libTidy'... it should just replace the previous... Strongly support - > One thing we recommend is when you must bring in a newer tidy > to build edbrowse you *have* to delete the old one and make > the new one the only tidy in the distro, then of course that > will be the only one cmake can find and there shouldn't be trouble. And, as you can see, library name changing does /NOT/ really solve this... despite accidentally working in the one specific case... HTH Regards, Geoff.