Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot omit libraries from install #2

Closed
dubiousjim opened this issue Apr 6, 2010 · 9 comments
Closed

Cannot omit libraries from install #2

dubiousjim opened this issue Apr 6, 2010 · 9 comments

Comments

@dubiousjim
Copy link

Trying to update the Arch "pandoc" package, which installs only the pandoc binaries and manpages, without Haskell libs.

Have all Haskell build dependencies, using ghc 6.12.1, trying to build pandoc 1.5.1.1.

This works:
runhaskell Setup configure --prefix=/usr --docdir=/usr/share/doc/pandoc
runhaskell Setup build
runhaskell Setup copy destdir=$pkgdir # supplying Arch's packaging chroot

But then all the libraries get installed. Former versions of this package added the "-f-library" option to the Setup line. However then the build fails with:

src/pandoc.hs:50:0
    error: missing binary operator before token "("

Hence this report.

Please advise what's the proper instructions to build from source (i.e. without cabal) if one wants to install only the executables not the libraries.

Worst case, I can have the build script install everything to the chroot and then delete the libraries before compressing the package. But I'm guessing those aren't the "proper instructions."

@jgm
Copy link
Owner

jgm commented Apr 6, 2010

That's weird. Normally Cabal defines a CPP macro MIN_VERSION_base to indicate the version of the base library that was used in compiling. I check against this to deal with differences in UTF8 handling between GHC 6.12 and previous versions. Apparently this macro is not being defined when the library is not built. I think this might be a Cabal bug; at least, the documentation gives no reason to think it would work this way.

Looks like if you reproduce the "Build-depends" fields of the Library stanza in the Executable stanza (in pandoc.cabal), it works. But I should get in touch with Cabal people to figure out whether or not there's a bug here.

@jgm
Copy link
Owner

jgm commented Apr 7, 2010

Update: This seems to be due to a change in Cabal 1.8. Now Cabal will ignore build-depends in the Library stanza if Buildable is False. That means I need to either get rid of the "library" flag, or repeat the Build-depends in the executable stanzas. Either solution will work, but the latter involves ugly and error-prone repetition. So now I'm thinking I should just get rid of the "library" flag. It's hard to see what use it is, anyway. You need to have lots of Haskell libraries installed in order to compile pandoc anyway, so why would you then object to installing one more? Packagers who want to install just the pandoc executable, and don't want ANY haskell libraries installed, should presumably build in a chroot (where the needed library dependencies can also be installed). Does that seem reasonable?

@jgm
Copy link
Owner

jgm commented Apr 10, 2010

I removed the library flag in 7d8c8c7.
Starting with the next release, the arch package will have to be modified.

@dubiousjim
Copy link
Author

Hi John, did you get the reply I sent a few days ago through the github interface? Basically, I was asking whether you could explain what difference the library flag makes? Or point me to where to find out. I'm guessing I need to read the cabal docs.

@dubiousjim
Copy link
Author

The impression I have right now of the change you've made is that one can no longer include "-f-library" on the "runhaskell Setup configure ..." line. So the result is that the "runhaskell Setup copy ..." line will install the libraries together with the executables. So if we want an executable-only package, our package script will have to itself take care of pruning the libraries out of the chroot that is going to be compressed into the package. Right? Easy enough to manage. (In fact, that's what my own local version of the package script is doing right now.)

EDIT: Previous maintainer of this packaged dropped it, so I've adopted it. Can you take a look at this build script

@jgm
Copy link
Owner

jgm commented Apr 10, 2010

Yes, right, -f-library was supposed to disable building and installing the library. Now you'll have to deal with this another way. I don't know much about arch build scripts, but yours looks like it should work, as far as I can tell.

@dubiousjim
Copy link
Author

Yeah, the arch-related details don't matter much. I was just checking if it should be ok to delete the stuff pandoc's install step put into /usr/lib, and also the /usr/share/pandoc-VERSION/markdown2pdf script (which you said was uneccessary and no longer maintained). Here's what ends up left (after some things are moved around):

/usr/bin/markdown2pdf
/usr/bin/pandoc
/usr/share/licenses/pandoc/COPYRIGHT
/usr/share/man/man1/markdown2pdf.1.gz
/usr/share/man/man1/pandoc.1.gz
/usr/share/pandoc-1.5.1.1/data/LaTeXMathML.js
/usr/share/pandoc-1.5.1.1/data/MathMLinHTML.js
/usr/share/pandoc-1.5.1.1/reference.odt
/usr/share/pandoc-1.5.1.1/s5/default/framing.css
/usr/share/pandoc-1.5.1.1/s5/default/opera.css
/usr/share/pandoc-1.5.1.1/s5/default/outline.css
/usr/share/pandoc-1.5.1.1/s5/default/pretty.css
/usr/share/pandoc-1.5.1.1/s5/default/print.css
/usr/share/pandoc-1.5.1.1/s5/default/s5-core.css
/usr/share/pandoc-1.5.1.1/s5/default/slides.js.comment
/usr/share/pandoc-1.5.1.1/s5/default/slides.js.packed
/usr/share/pandoc-1.5.1.1/templates/context.template
/usr/share/pandoc-1.5.1.1/templates/docbook.template
/usr/share/pandoc-1.5.1.1/templates/html.template
/usr/share/pandoc-1.5.1.1/templates/latex.template
/usr/share/pandoc-1.5.1.1/templates/man.template
/usr/share/pandoc-1.5.1.1/templates/markdown.template
/usr/share/pandoc-1.5.1.1/templates/mediawiki.template
/usr/share/pandoc-1.5.1.1/templates/opendocument.template
/usr/share/pandoc-1.5.1.1/templates/plain.template
/usr/share/pandoc-1.5.1.1/templates/rst.template
/usr/share/pandoc-1.5.1.1/templates/rtf.template
/usr/share/pandoc-1.5.1.1/templates/texinfo.template

@jgm
Copy link
Owner

jgm commented Apr 10, 2010

Yeah, that should be all you need. You might want to have it install the README somewhere, too (also BUGS and changelog). These would naturally go in /usr/share/pandoc-1.5.1.1. But they're not absolutely necessary.

@dubiousjim
Copy link
Author

Thanks, you caught a packaging bug.

jgm added a commit that referenced this issue Aug 7, 2017
Note that we still don't support macros with fancy parameter
delimiters, like

    \def\foo#1..#2{...}
link2xt pushed a commit that referenced this issue Nov 5, 2017
Patch for Text.Pandoc.Builder.simpleTable generating empty tables (Issue 301)
jgm added a commit that referenced this issue Aug 14, 2018
For example:  `\def\foo#1[#2]{#1 and #2}`.

Closes #4768.  Also fixes #4771.

API change:  in Text.Pandoc.Readers.LaTeX.Types,
new type ArgSpec added.  Second parameter of Macro
constructor is now `[ArgSpec]` instead of `Int`.
bubifengyun added a commit to bubifengyun/pandoc that referenced this issue Sep 22, 2018
Solve bug jgm#4716,

now, the old text can works, but it need `usepackage{etoolbox}` for `\ifdef`.
if user want to use in mathescape=true for `listings` package, the following can be added to the template when needed.

```latex
\makeatletter
\newcommand{\ifmathescape}[2]{%
  \lst@ifmathescape jgm#1\else jgm#2\fi
}
\makeatother
\let\ifdisableEscapeString\ifmathescape
```
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants