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.
- Removed documentation generation from CMake.
- These functions are now available in the api repository.
- Changed documentation directory to man to better illustrate its purpose.
CPack generated RPM failed to install due to the RPM
owning directories owned by filesystem packages.
Exclude mandir directories from CPack.
Resolves https://github.com/htacg/tidy-html5/issues/364
Add the ever present language_en.h to the sources. This does nothing
really, but is important in MSVC IDE project source searches.
Also added win32tc.h even though it is not presently used.
There was an idea to mark this function deprecated, such that if used the
developer would see a warning. But this was never implemented in a cross
platform way.
So for now revert to circa Jan 2015 when Jim added a build date to the
version.txt file. And now both LIBTIDY_VERSION and RELEASE_DATE macros are
established in CMakeLists.txt, and picked up in version.h.
The idea is the date will now march forward with the version number, side
by side in version.txt. Although have left tidy.c only emitting the
version on the --version command.
After this function has been marked deprecated for several release periods,
only then should consideration be given to potentially removing it.
First many other projects do this, and it seems a good choice.
Due mainly to windows where the static and shared libraries have the same
name, appended an 's' to the static library.
The tidy console app will use the static library, since to build the man
page tidy may need to be run before the shared libraries are installed.
And this makes the windows tidy exe a stand-alone app. No DLL install
issue.
This addresses issue #194, and possibly #190
The recommended place to run cmake is in the build/cmake directory,
but have changed a relative path to an absolute path which should
allow cmake to be run ANYWHERE!. See bottom of Issue #193
Also a few other minor tweak to CMakeLists.txt
