The process was too fragile. It made too many assumptions about
available libraries (which failed sometimes when sandboxes were
used). This is a low-tech solution. The only drawback is that
`man/pandoc.1` is a generated file in the repository. It will need
to be regenerated periodically when README changes.
The pandoc.1 man page is generated automatically after the cabal
build process. It goes in `data/pandoc.1`. It can be obtained
by the user who installs pandoc via cabal thus:
pandoc --print-default-data-file pandoc.1 > pandoc.1
+ Removed `--man1`, `--man5` options (breaking change).
+ Removed `Text.Pandoc.ManPages` module (breaking API change).
+ Version bump to 1.15 because of the breaking changes, even
though they involve features that have only been in pandoc
for a day.
+ Makefile target for `man/man1/pandoc.1`. This uses pandoc to
create the man page from README using a custom template and filters.
+ Added `man/` directory with template and filters needed to build
man page.
+ We no longer have two man pages: pandoc.1 and pandoc_markdown.5.
Now there is just pandoc.1, which has all the content from README.
This change was needed because of the extensive cross-references
between parts of the README.
+ Removed old `data/pandoc.1.template` and
`data/pandoc_markdown.5.template`.
This change adds `--man1` and `--man5` options to pandoc, so
pandoc can generate its own man pages.
It removes the old overly complex method of building a separate
executable (but not installing it) just to create the man pages.
The man pages are no longer automatically created in the build
process.
The man/ directory has been removed. The man page templates
have been moved to data/.
New unexported module: Text.Pandoc.ManPages.
Text.Pandoc.Data now exports readmeFile, and `readDataFile`
knows how to find README.
Closes#2190.
Reason: starting with Cabal 1.8, installing pandoc with '-library
+executable' did not work, since the build-depends in the Library
stanza were ignored. The problem could be solved by repeating the
build-depends in the Executable stanza, but this seems non-ideal
(and might lead to errors later on). The '-library' option isn't
so useful anyway, since to compile pandoc in the first place, you
need a large number of Haskell libraries installed, and in this
case, why balk at another? It was chiefly intended for packagers,
but packagers will need to use a chroot environment anyway, and
they can then simply copy the executable and not the library.
Thanks to Jim Pryor for calling the problem to my attention
in connection with an arch linux package.
It is easier for releases if debian packaging is separate.
+ Removed debian directory and references to debian in Makefile and INSTALL.
+ Made COPYRIGHT and changelog standalone files rather than symlinks to
debian directory.
git-svn-id: https://pandoc.googlecode.com/svn/trunk@1422 788f1e2b-df1e-0410-8736-df70ead52e1b
+ Removed utf8-string cabal configuration flag.
+ Instead, we just include System.IO.UTF8 and Codec.Binary.UTF8.String
from utf8-string package in the source tree, avoiding a dependency
on utf8-string and avoiding crufty custom UTF8 code. (The old
Text.Pandoc.UTF8 had problems with the getContents function.)
+ Removed lots of CPP directives that are no longer needed.
+ In Setup.hs, use '-i..' in running RunTests.hs, so the local UTF8
code will be found.
git-svn-id: https://pandoc.googlecode.com/svn/trunk@1411 788f1e2b-df1e-0410-8736-df70ead52e1b
+ Added Text.Pandoc.UTF8
+ Changed flag name from utf8 to utf8-string
+ Changed CPP MACRO from _UTF8 to _UTF8STRING
+ Import IO functions from Text.Pandoc.UTF8 when utf8-string not available.
+ Removed utf8-string dependency from debian/control.
+ Removed pandoc.cabal.ghc66; we no longer support GHC 6.6
+ Modified INSTALL instructions
git-svn-id: https://pandoc.googlecode.com/svn/trunk@1383 788f1e2b-df1e-0410-8736-df70ead52e1b
