Closed turion closed 2 years ago
I don't have an opinion, whatever you think is best.
Btw, what would the backends be ? Do you mean dunai and essence-of-live-coding ?
No, I meant external packages like gloss
or terminal
.
Probably the question is more relevant for essence-of-live-coding
where there are more backend libraries, see https://github.com/turion/essence-of-live-coding#setup-and-ghci-integration
Hi @turion, I'm not quite sure what's the best pattern here. I guess right now, you would depend on rhine
and rhine-gloss
and that would give you the Rhine backend you want (would be a good addition I suppose to be able to pass-through the glut
or glfw
flag to gloss
?).
With your suggested change we would be able to depend only on rhine
and choose the backend based on a cabal flag.
From that point of view, I'm not so sure that it's a huge improvement and I'd be tempted to leave it as is and see if it becomes a problem or a requested feature in practice? There might be discoverability and documentation aspects to consider too...
With your suggested change we would be able to depend only on
rhine
and choose the backend based on a cabal flag.
Yes, exactly.
From that point of view, I'm not so sure that it's a huge improvement and I'd be tempted to leave it as is and see if it becomes a problem or a requested feature in practice? There might be discoverability and documentation aspects to consider too...
Right. Also, testing is an issue because we'd have to test rhine
with every combination of flags.
Ok, let's leave everything as it is right now.
Since now,
rhine
has gone the way of having one main libraryrhine
and many small extra librariesrhine-some-backend
, for each backend library that it connects to. I've been wondering whether it's cleverer to join them all in a single library, and usecabal
flags to decide whether support for a specific backend would be pulled in. Does anyone have an opinion on this?CC @miguel-negrao @jmatsushita