Add compatibility headers #420
Conversation
|
@AdamMajer thank you for the PR... always welcome... Yes, this was a tough decision for our first release in about 7+ years... see #223 and others... you will note the alternative of installing in like So while there will remains a possible conflict with other But after 7+ years I doubt there would be much current software out there using those old headers... but maybe... Other major packages, that are likely to have links with libtidy, like say PHP, and hopefully others... already use the re-named headers from using later tidy sources, maybe due to no distribution updates, to build their own distribution libraries and/or other binaries... so these are aware... All known windows apps that use lib tidy DLL never depend on a globally installed Tidy DLL! It does not exist, yet! Most have updated from source, so this is not needed in windows... And that is good because the Will leave it for a little time, for others to comment, but looks ok to me, at this time... If there is a use case, why not? Comments welcome... |
|
On Wed, 15 Jun 2016 18:08:10 -0700
I think apache2 tidy mod broke along with others that now build
That pragma could be commented with a #ifdef GNUC for example. And When I still ship programs for Windows, I always use DLLs, although |
|
@AdamMajer yes, absolutely agree, even after 7+ years, there may be cases where compatible (old) headers may be required...
If you are referring to - http://mod-tidy.sourceforge.net/ - yes, I note src/mod_tidy.c (2006) uses "buffio.h". But in the source I built in linux, and windows, had embedded an old tidy source, with the old headers, so does not use any installed tidy-dev headers... and in fact effectively uses tidy in a static like form, ie not using a shared library... And also note that site has not been updated in quite a while, and still points people to our old historic dormant SF site... must add it to my TODO list to try to contact them... But, like I say, there could be others, thus support this PR... And yes there are various macros that can be used as a substitute for the gcc #warning "ABC"... But in Windows people who build tidy from source would have no need to enable this option... Seldom, probably never would a windows user actually 'install' tidy, at least not to the meaningless Program In development, I do install tidy into a Will merge this shortly... |
|
Arch Linux is working around this with symlinks: https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/tidy&id=482ab3f78fcd66828214eafeb6b2d66c11306e1c I've had a request to do the same for the Debian package of version 5.2.0, does that seem like a reasonable short-term solution? |
|
On 06/18/2016 07:19 PM, Geoff McLane wrote:
Just to be clear 100%, NONE of Linux distributions would use static linking (maybe except ALL Linux distributions use dynamic linking. It's been like that since the beginning. There are major problems with
|
Out of this list (using codesearch.debian.org to lookup usages of buffio.h and filtered whether they build-depend on only edbrowse also has So you broke 14 of packages that build-depend on |
In older versions of tidy, these headers were defined. Now, they are renamed to tidybuffio.h and tidyplatform.h. This may be more of a consistent naming scheme, but it breaks current software. Re-add these headers and add compile time warning when such a header is used.
|
Updated header patch so that it will not cause errors on non-gnu (and non-clang) compilers, which basically means MSVC and niche compilers. |
|
While not totally happy! with this, do see a certain use case... Anyway, now merged... thanks @AdamMajer And version bumped to 5.3.6... |
In older versions of tidy, these headers were defined. Now, they are
renamed to tidybuffio.h and tidyplatform.h. This may be more of a
consistent naming scheme, but it breaks current software.
Re-add these headers and add compile time warning when such a header
is used.