Explore seperate librarys and a unified cabal.project build and stack build

amnh / PCG

𝙋𝙝𝙮𝙡𝙤𝙜𝙚𝙣𝙚𝙩𝙞𝙘 𝘾𝙤𝙢𝙥𝙤𝙣𝙚𝙣𝙩 𝙂𝙧𝙖𝙥𝙝 ⸺ Haskell program and libraries for general phylogenetic graph search

28 stars 1 forks source link

Explore seperate librarys and a unified cabal.project build and stack build #126

Closed recursion-ninja closed 5 years ago

recursion-ninja commented 5 years ago

Currently we have many internal libraries in a single .cabal file. There are a number of issues with ths:

This doesn't play very nicely with stack
The .cabal file is monolithic and difficult to locate information
It lacks meaningful description of libraries
Difficult to isolate tests and benchmarks for libraries with their respective library code.

Ideally, we would have a dozen individual libraries that can all be build separately and a halve-dozen executable to be build individually.

This should speed up build times and serve to increase clarity.

recursion-ninja commented 5 years ago

The tool hpack might be useful for automatically generating the .cabal files for our many sub-libraries, integration tests, and executables without repeating a lot of boilerplate specification manually for each "build target". Right now we are duplicating the litany of GHC flags to pass to each build target, along with the relevant FFI information if applicable.

I'm going to first break the monolithic .cabal file into proper sub-libraries, then explore using hpack to add a bit of sanity to maintaining all of the sub-library's specifications.

recursion-ninja commented 5 years ago

This has been completed. See this commit 317f8f8.

I didn't incorporate hpack because it doesn't appear that you can shared data between packages in a project and the goal was to not duplicate information across our many packages and executable.