support multiple .cabal files

[bos]

(Imported from Trac #734, reported by guest on 2010-09-06)

if there are several *.cabal files in the working
directory, then "cabal configure" complains,
and does nothing. That's OK, but it should then
have an option for picking one of these files
(cf. "make -f FILE").

[bos]

(Imported comment by @rrnewton on 2010-09-06)

+1

As far as I can see there's no reason not to provide a command line switch for this.

I was just considering introducing a .cabal file for each benchmark in a directory. Having to place them all into their own directories makes this refactoring significantly more daunting.

[bos]

(Imported comment by @dcoutts on 2011-11-07)

Unfortunately this is harder than it looks. The underlying Cabal build system interface does not allow for multiple .cabal files in a directory. Also, they would all need to share the same Setup.hs.

The simple approach would be to tell the build system which .cabal file to look at. Another would be to allow the single build system to see all the .cabal files and build all the components.
Either approach will require an update to the Cabal build system interface spec.

[rrnewton]

By the way, this seems related to the issue of whether multiple targets can be build individually within a given cabal file. It doesn't look like there's any ticket for this to link to, is there?

Either approach gives you independent build targets. The use case I was thinking of was a directory full of example programs, where either multiple cabal files, or a large cabal file with many executable entries would work. But, in the later case it would be nice to be able to invoke cabal to build only one target and then have something outside (like make -j) drive the building of multiple examples in parallel.

Of course it's also possible (but tedious) to place every example in its own directory and generate cabal files (including some duplicated bits).

[BardurArantsson]

I think this is entirely superceded by #2631 and should be closed.

[deepfire]

A related thread: https://mail.haskell.org/pipermail/libraries/2011-January/015608.html