Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deprecate <target>-specific flags in favour of flags that will be applied to each component built. #9747

Open
alt-romes opened this issue Feb 28, 2024 · 1 comment

Comments

@alt-romes
Copy link
Collaborator

alt-romes commented Feb 28, 2024

Posting from a thread in the Cabal matrix channel:

To be very honest (perhaps controversially), I feel like we should deprecate all of these flags specific to a kind of component (--enable-executable-profiling + --enable-library-profiling + --enable-executable-dynamic + --enable-executable-static + --enable-executable-stripping + --enable-library-stripping, etc...) in favor of flags which are applied to the component being built.

That is, cabal install <exe-target> --enable-stripping will strip an executable, cabal build <lib-target> --enable-stripping will strip the library...

--enable-profiling enables profiling for either the lib or executable target. If the target is all then every component gets profiling.

I think it would be just so much simpler both implementation and usability wise.

I often see users simply apply all variations of the flag to get the behaviour they want because it is otherwise not understood how to profile what they want exactly

@dcoutts
Copy link
Contributor

dcoutts commented Feb 28, 2024

IMHO, I've never liked the build/install flags that affect the configuration. I'd prefer if configuration flags were used by the users at configuration time, and then build would just build.

Otherwise things get rebuilt when one uses or doesn't use the flag, since it changes the config.

In some cases, like profiling, we should be able to say that logically we configure to have profiling flavours available as targets but not necessarily build them, so that the user can then choose to build profiling variants or not without changing their config.

Historically, profiling/non-profiling had to be different configurations rather than parallel configurations.

Again, this stems from Custom Setup.hs, because it installs whole packages with normal, profiling or both. Whereas we'd like to be able to install package A as normal, and again (registered separately) as profiling.

Thus if we need to build a profiling version we don't need to rebuild dependencies with profiling+normal, we just build additional ones with profiling only.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants