Allow foo.etlas rather than foo.cabal?
ekmett opened this issue · 9 comments
I have a bunch of packages that I'm looking at configuring to build with both etlas and cabal. I can merge a significant cross-section of the etlas patches directly into my repositories, and am happy to do so wherever it doesn't cost functionality.
However, in some cases I have to disable custom builds when building with etlas, even though I need the custom build on the cabal side. Consequently a single cabal file doesn't serve both needs appropriately.
It'd be amazing if etlas could do something like look for foo.etlas and prefer it to foo.cabal if it was present -- something like how GNUMakefile gets preferred to Makefile in GNU tooling.
This would enable me to package both together, (say, by adding the .etlas file as an extra-source-files: in my .cabal file, so that it'd go along for the ride up to hackage and reduce the burden I place on eta-hackage.
I realize this may be a bit awkward as there are probably a bunch of places where the old cabal code has hardcoded the notion of where the config comes from, how to get stuff from hackage.
From an "X/Y Problem" perspective, I'm mostly just looking for a way to work with both etlas and cabal in the same working folder, when they have sufficiently divergent needs that the one config file can't serve both masters, the "how" is far less important than the "what."
We were thinking of a having a separate file extension in the long run, giving the dhall format more preference if it is found.
But as a quick way to make this work with little change, we could do the mapping below where the latter has more preference.
foo.cabal -> foo.etlas
cabal.project.* -> etlas.project.*
@jneira I remember you where working on this - how much more is left to get this in a working state?
For your specific need of eliminating custom builds when compiling with etlas, we can have etlas emit a warning that custom builds are not yet supported instead of terminating it like it does now and have it treat it as a Simple build. This would eliminate the need for several patches on eta-hackage as well.
That’d probably be enough to unblock me until a nicer solution comes along.
Ok I've updated etlas to ignore custom build types and build it anyway using the simple build type. Unfortunately, the warning is not being emitted as intended, but this should be enough to unblock you for now.
I've bumped the etlas submodule on the main eta repo as well, so doing a submodule update and running ./install.sh should be enough to get everything working.
Thanks!
@rahulmutt dhall-to-etlas is working so only left integrate it in etlas to load the cabal GenericPackageDescription from the dhall file instead cabal one if present