Created attachment 186427 [details]
First attempt at a new port for hs-xcb-types
New port needed to fix x11-wm/qtile (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222363).
The new port provides a library that allows parsing XCB data into Haskell data structures.
This is my first attempt at contributing to ports. Thus I would appreciate if an experienced porter could look a little more closely at my suggested port. I tried to follow the instructions in the Porter's Handbook but there are a few things that I simply don't know. I'm not familiar with Haskell and even less with Haskell on FreeBSD. Should the maintainer be set to haskell@FreeBSD.org or to ports@FreeBSD.org?
Also the port linter does have a few complaints on my port - but these complaints also apply to other Haskell ports that are already in the tree, so I assume they can be disregarded. Here's an example anyways:
"WARN: Makefile: DYNAMIC is listed in OPTIONS_DEFINE, but no PORT_OPTIONS:MDYNAMIC appears."
I would assume this comes from bsd.cabal.mk and since it's not an error but just a warning, it might be ok.
Stage QA shows some errors like this one:
"Error: /tmp/hs-xcb-types-0.8.0/lib/cabal/ghc-8.0.2/x86_64-freebsd-ghc-8.0.2/libHSxcb-types-0.8.0-ISNfa4NDD1T4Kl5O6U89as-ghc8.0.2.so is linked to /usr/local/lib/cabal/ghc-8.0.2/x86_64-freebsd-ghc-8.0.2/libHSxml-1.3.14-8mm35V7Je6c5Jp6wNteE
zV-ghc8.0.2.so that does not belong to any package"
I'm not sure what this is all about and couldn't find a solution. It also happens with other Haskell ports that were already committed and obviously doesn't stop the port from actually working. Still it looks a little scary.
And finally there's output like this:
"actual-package-depends: dependency on /usr/local/lib/libgmp.so not registered (normal if it belongs to base)"
Should I add all the libraries listed there as RUN_DEPENDS?
The port works for me in that it provides what is needed to build another port that depends on it. Also checking it with "synth test" worked well. For that reason I believe that the port is not in a horrible state but some of the above issues probably need to be taken care of.
Any advice on what I should do next to eventually get this committed would be very welcome.
I have not reviewed the port thoroughly, but I did look for the category so that I could add it to the Summary.
My quick guess is that this port would be better off in another category, e.g., converters, textproc, or something similar.
Can you explain why this port is needed for qtile? Since its a python port?
(In reply to Mark Linimon from comment #1)
My understanding is that it doesn't really convert anything that is of much use to other programs. It merely provides an interface to use xcb with Haskell and I thought that ports like that belonged in the category that they are actually used with. But I'm just getting started with ports development and if you feel that it belongs somewhere else I'm of course open to modify the port. Thanks for your suggestion!
(In reply to William Grzybowski from comment #2)
Sure. This port is not actually used by Qtile at all. But it is a build-time dependency for py-xcffib which is the new dependency for Qtile after they dropped py-xpyb due to inactive upstream and long-standing bugs in it. I also found it quite strange to mix in Haskell for a Python binding. Obviously some people disagree. As the author puts it:
"Why is the binding generator written in haskell? Because haskell is awesome."
Once this port is in good shape and got committed, I will submit hs-language-python, the other missing port for py-xcffib.
(In reply to Michael Reim from comment #3)
The release version of xcffib (as published on PyPI) has pregenerated
binding files, so it does not actually need any Haskell dependencies.
Since ports r482351 we have it in the ports tree as x11/py-xcffib,
so I'm closing this here as it appears to no longer be needed.