2017-12-28 22:06 GMT+01:00 Ashish SHUKLA :

On 28/12/17 9:11 PM, Palle Girgensohn wrote:

...

0. First, is somebody already working on porting postgrest? :) Only speaking for myself, I'm not working on it.

Me neither. I think you are safe to go with it.

...

1. The postgrest project suggest using devel/stack to get all ports [2]. I assume this is a shortcut that cannot really be used with a port.

I guess no, it cannot be. That is for building the project interactively, and it is not targeted for packagers. We do not use Haskell Stack for packaging, that is more intended for development.

...

But perhaps the stack tool can be used to get a list of dependant ports? Or is the postgrest.cabal file in the root enough to simply find all dependencies?

Yes, the .cabal file can give you the immediate dependencies, but not their (transitive) dependencies.

I don't think it matters how you find out all dependencies (or which mechanism is kept up-to-date by developers), as long as list of the dependencies is accurate.

Yes, that is right.

Ideally, it would be nice to keep .cabal file, but it all depends on developers.

We always keep the .cabal file as the hs- ports still rely on the Cabal library to drive the build process. Basically, what we have in the ports tree is just a moderately thin layer of wrapping all around this.

we used hsporter[1] to generate port. I'm not sure how much accurate it's, but you can use it to bootstrap your work.

For what it is worth, you do not need to use the hsporter -- I usually copy the files for one of the already existing hs- ports and change their contents for the new port, it should be intuitive (but please poke use if not). hsporter will not create ports for the dependencies anyway, you will have to do it yourself. As far as I recall, bsd.cabal.mk is helpful enough to tell the port of which Cabal package is missing on trying to build the port, so you can do the porting incrementally by always adding them to the fold (until you reach ports with no further dependencies).