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

cabal build --enable-profiling should use a separate build directory #6873

Open
yav opened this issue Jun 3, 2020 · 4 comments
Open

cabal build --enable-profiling should use a separate build directory #6873

yav opened this issue Jun 3, 2020 · 4 comments

Comments

@yav
Copy link

yav commented Jun 3, 2020

It is quite common to alternate normal and profiling builds while developing. Currently, cabal uses the same build directory for both, which results in a lot of rebuilding. The current workaround is to manually specify separate build directories for each type of build, which works but is noisy.

This seems easy to fix: use some other build directory by default if --enable-profiling is present (e.g., dist-profiling). Users can still use --builddir to pick a different one, if they'd like.

@TomMD
Copy link
Contributor

TomMD commented Jun 3, 2020

The problem is wider than --enable-profiling, it includes any flag that impacts compilation. Any solution should consider solving this for all flags.

One popular example is ghcide and company. They compile with -w and many project... don't. The end result is building via cabal build will cause a significant re-build, which then gets over-written by the invocations of the IDE. There is also a race here, but I'll make a separate ticket.

@yav
Copy link
Author

yav commented Jun 3, 2020

Well, I am not sure why the warning flags should affect compilation, so that might be a separate issue.

The general problem seems a bit trickier to solve as I am not sure that I'd want a separate build directory every time I change a flag that affects compilation, but maybe that's OK?

Anyway, using profiling is a very common thing to do, and I can't think of any reason why you might want you profiling build to overwrite your normal build, so I'd be happy with the simple change to use a different directory in that particular case.

@phadej
Copy link
Collaborator

phadej commented Jun 3, 2020

See #5314 (review)

Separate directory is not proper solution.

@yav
Copy link
Author

yav commented Jun 4, 2020

I wasn't suggesting that we add a subdirectory to the existing build directory but rather, to simply use a whole separate directory. So this amounts to just a different set of default settings: currently the build directory is always dist-newtyle unless you explicitly specify it. I was suggesting that if --enable-profiling is present, then the default build directory becomes dist-prof or something, that's all.

This is the workaround that people are using anyway, and while I don't claim to be a cabal expert, it seems perfectly reasonable to keep profiling and normal builds separate.

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

4 participants