search

haskell / cabal

Official upstream development repository for Cabal and cabal-install
https://haskell.org/cabal
Other
1.61k stars 691 forks source link

Specifying flags for all non-local packages in cabal.project #3719

Open quyse opened 8 years ago

quyse commented 8 years ago

As far as I know currently there's no way to specify build options for all non-local packages at once while new-building. Options from global/local cabal.config don't apply to them, and package * in cabal.project doesn't work. I'm not sure why it's forbidden, is there any problem with changing options for all packages?

I'm interested in particular in split-objs, optimization, documentation, but it would be nice to support setting of any option for all non-local packages via cabal.project or some other way.

ezyang commented 8 years ago

The basic problem is it's not possible/no one knows how to set options for packages which are NOT inplace (non-local, in your words).

quyse commented 8 years ago

Sorry, I'm not really familiar with Cabal internals. It sounds surprising to me, because why it's possible to set options for all packages via global ~/.cabal/config file when not using new-build, but it's not possible to set options for all packages when using new-build?

ezyang commented 8 years ago

No it should be possible, it's probably not even that difficult of a code fix. I think the primary problem here is a documentation one; figure out what we want cabal.project to mean, and make sure it means that. I've summarized the issues here: #3720

ezyang commented 8 years ago

OK, having worked on the documentation, I think you are right, and there is no way to apply flags to ALL packages that are transitively reachable, and it seems like it would be useful.

Some thoughts:

  1. In all the use-cases you specified, it's not that you specifically want to single out non-local packages; you just want to apply flags to everything that is transitively reachable. (That is what's suggested by package *.) I'm trying to think of a case where this is NOT what you want and I'm having a hard time.
  2. We can't actually rebuild everything: anything that's in the global package database which the solver decides to pick (regardless of your settings) will get used. This is already true if you say, e.g., package base, but it's something to be aware of, e.g., re documentation.
  3. What's a good syntax for cabal.project? package * is obvious and not a bad choice. The only thing I dislike is it implies that wildcards are available in package, which they are not. But maybe that's not a big deal.
quyse commented 8 years ago
  1. You're correct, my primary usecase is that I would like to apply flags to everything that's transitively reachable (i.e. everything what's affecting the end result of a build). For example, I want to build an executable of minimal size and maximum performance, so I need to have correct split-objs and optimization settings applied to basically all packages my executable depends on. However I think it makes sense to have a distinction and be able to apply some settings only to local (or in-place? didn't get the difference yet) packages, and some settings only to non-local packages (packages from Hackage). For example, what about minor GHC options in project file, like warning suppression options? If I put ghc-options: -fno-warn-tabs into project file, I probably prefer to not apply this option to non-local (Hackage) packages, hence reusing stored binaries for them instead of building them second time, because I'm not going to look into their build logs anyway.
  2. I understand we cannot change anything about prebuilt packages like base, though I thought they are already built quite optimal (with optimization, documentation and split-objs enabled).
  3. local-package-options and non-local-package-options or smth like that may be used if local/non-local distinction is deemed useful. And then all-package-options may be used instead of package * if it's looking better.