Publish PGF2 in Hackage

Question

Publish PGF2 in Hackage

inariksit opened this issue 4 years ago · 16 comments

Would it be possible to publish the Haskell bindings to the C runtime in Hackage? That would make it easier to distribute GF applications written in Haskell.

Answer 1 · 2020-07-07T10:10:22.000Z

Duplicate of #32

Answer 2 · 2020-07-07T10:15:27.000Z

Sorry, I remembered that 32 was just about the haskell, not haskell-bind. :-P

Answer 3 · 2020-07-07T10:18:07.000Z

Oh no you're right, sorry myself.

Answer 4 · 2020-07-11T19:11:43.000Z

I created a "candidate" upload on Hackage here: https://hackage.haskell.org/package/pgf2-1.1.0/candidate
This should be reviewed and tested before publishing, in particular by @krangelov. One can install locally with:

cabal install https://hackage.haskell.org/package/pgf2-1.1.0/candidate/pgf2-1.1.0.tar.gz

I updated the cabal file and README a little, those updates are on the branch pgf2-hackage which I'll PR now.

Answer 5 · 2020-07-11T19:24:39.000Z

Also I wonder if the pgf-shell example should be removed, or at least not built by default. Most of the time if someone is installing the pgf2 Haskell library they don't want an extra toy executable compiled for nothing.

Answer 6 · 2020-07-13T06:54:17.000Z

Is it possible to include the C libraries as well, so that only installing PGF2 from hackage is enough? For instance, the MiniSat package contains the C sources and a makefile along with the Haskell sources.
The cabal file for MiniSat contains .c and .h files in extra-source-files and a keyword c-sources.

Answer 7 · 2020-07-13T09:40:51.000Z

Yes that would be a lot more convenient wouldn't it... I'm not so experienced with this kind of thing but I'll give it a shot.

Answer 8 · 2020-07-13T10:36:53.000Z

Awesome, thank you!

Answer 9 · 2020-07-13T15:20:53.000Z

Hi, Go ahead and upload the package on Hackage if you want. However, this wouldn't make the installation much easier since people would still have to install the C runtime. You could make a Cabal file which compiles C code but the situation here is different from MiniSat. The C code in MiniSat is used only by the Haskell library and it is statically linked with it. Cabal supports that scenario well. On the other hand our C runtime is meant to be shared from several languages. For that reason the C runtime is a shared library instead of static library. To make the setup really easy there should be binary packages somewhere for the C code.

…

On Mon, 13 Jul 2020 at 12:37, Inari Listenmaa ***@***.***> wrote: Awesome, thank you! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#68 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEYFSZEIX7Y72NBKC445GOLR3LPVHANCNFSM4ORSIQLA> .

Answer 10 · 2020-07-14T07:25:44.000Z

Okay, thanks for the explanation! Can we make a binary package? Ease of installation is really my main motivation for requesting this, and if one has to install the C library separately, it's not a big improvement to only have the Haskell files from cabal.

Answer 11 · 2020-07-14T09:18:35.000Z

I agree that the Haskell-only package is not very valuable and the goal should be a package which includes the runtime itself.
If we want to pre-build the binaries for distribution, I guess the headache here is that we have to have different versions for different OS's. This is probably doable using Docker locally and/or via GitHub actions. I could look into this.

When you say that the library is "shared", what exactly does this entail? Does it intrinsically affect the way the code is written, or is it just some flags or whatever passed at compile time? If the latter, then we could build a separate non-shared version of the runtime purely for distribution with the Haskell package (which is then compiled by client rather than distributing binaries).

Answer 12 · 2020-07-14T15:05:26.000Z

It is possible in principle to statically link the C code to each of the bindings but I don't find this as a very pleasing solution. This would mean that the same code is compiled and linked into several binaries. As it is right now it is also nice that I can only recompile the C runtime wouldn't the need to recompile the bindings.

…

On Tue, 14 Jul 2020 at 11:18, John J. Camilleri ***@***.***> wrote: I agree that the Haskell-only package is not very valuable and the goal should be a package which includes the runtime itself. If we want to pre-build the binaries for distribution, I guess the headache here is that we have to have different versions for different OS's. This is probably doable using Docker locally and/or via GitHub actions. I could look into this. When you say that the library is "shared", what exactly does this entail? Does it intrinsically affect the way the code is written, or is it just some flags or whatever passed at compile time? If the latter, then we could build a separate non-shared version of the runtime purely for distribution with the Haskell package (which is then compiled by client rather than distributing binaries). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#68 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEYFSZFVGYSVKC4QH4V5W5TR3QPHVANCNFSM4ORSIQLA> .

Answer 13 · 2020-07-16T10:55:04.000Z

So if I wrote a script to compile the C runtime for Debian, MacOS and Windows using Docker, should it then be straightforward to include these binary libraries into the Cabal package?

Answer 14 · 2020-07-17T10:56:11.000Z

There is no way in cabal to include C packages but we can have the platform dependent packages somewhere and then we can instructions like: $ sudo apt get c-runtime $ cabal install pgf2 It can't be simpler than that.

…

On Thu, 16 Jul 2020 at 12:55, John J. Camilleri ***@***.***> wrote: So if I wrote a script to compile the C runtime for Debian, MacOS and Windows using Docker, should it then be straightforward to include these binary libraries into the Cabal package? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#68 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEYFSZCSD7PI7JZEFRNMZLTR33MBRANCNFSM4ORSIQLA> .

Answer 15 · 2020-07-21T11:25:02.000Z

I see. I think that publishing the PGF C runtime in mainstream package managers like apt or Homebrew might be a lot of extra work. Perhaps we should have the binary libraries compiled and stored in GitHub, then we just provide some one-liners in the README which will download them and put them in the right place on your system.

Answer 16 · 2020-08-03T20:56:30.000Z

I haven't done anything specific about distributing the compiled C runtime [yet], but I published PGF2 on Hackage anyway since I have a use for it: https://hackage.haskell.org/package/pgf2