cabal new-clean #3835
cabal new-clean #3835
Conversation
|
/cc @dcoutts |
| commandSynopsis = "Cleans up after a Nix-local build.", | ||
| commandUsage = usageAlternatives "new-clean" [ "[FLAGS]" ], | ||
| commandDescription = Just $ \_ -> | ||
| "Cleans up Nix-local build files such as .hi, .o, preprocessed sources, etc.", |
There was a problem hiding this comment.
Since you already mentioned nix-local-build in the synopsis, I think you can just say "intermediate build files".
|
I think that in the case of Related: #3600. |
Sorry, I don't understand this comment. Are you saying that I need to add hooks for Or are you saying I need to change the way the |
Maybe. That would be something like, running
Nope. The point is that some Custom setup scripts may drop build files in NOT dist-newstyle. Like a configure script might stick a header file somewhere random. A Custom clean would be able to remove the file, even if deleting dist isn't enough. FWIW, I think custom clean is a mistake and if you want something cleaned put it in the dist directory. And it's a pain in the ass because you end up building the Setup script, JUST to run clean. That's no fun. |
| let flags' = flags { cleanDistPref = toFlag distPref } | ||
| noExtraFlags args | ||
|
|
||
| pdfile <- defaultPackageDesc verbosity |
There was a problem hiding this comment.
This looks wrong. There's no reason to believe you actually have a specific package if you new-clean. Say you're in the top-level directory of a project. What is pdfile going to be here? Bogus.
Meta-commentary, I probably would NOT go about implementing this as a copy paste from the existing clean. Better to just do it from scratch, I think.
|
Needs a test. |
|
Thanks for the patch! Definitely filling a missing hole in the implementation. |
|
@RyanGlScott thanks for the contribution! I agree with @ezyang that we probably want to approach it from afresh. One significant change with the new-* commands is that they mostly work at the level of a whole project, and only sometimes at individual package level. So I think for new-clean the main thing we want to do is clean the whole project, which means rm -r'ing the dist-newstyle directory. That gets us 90% of the way there. Then there are some other bits and bobs. Package .cabal files can specify extra files to clean, and so those should be removed too. The equivalent of Whether or not we should run the "clean" hook of custom Setup scripts is a bit of an open question. It's rather annoying to have to compile a Setup script just so we can run clean, which 99% of the time does nothing more than rm the dist dir. What if we cannot configure the project or build the Setup scripts, does cleaning fail? I could be persuaded that clean being part of custom Setup is just a design flaw, and all generated files should live in dist except for those few listed in the extra clean files in the .cabal file. So I'd focus on whole-project clean first. If we really want to later we could think about adding "clean, but only this bit, not everything", e.g `cabal clean ./" to mean this target (in the same way we have build targets). But that's a bonus not a necessity. |
|
Oops, I was doing a rebase and accidentally closed this :\ I'll re-open when I've implemented the suggestions above. |
|
...or not. Sadly, the implementation has become substantially more complicated than when I looked at this last, and with my limited knowledge of the |
This is my first major contribution to
cabal-install, so I'm probably doing this all wrong. Please scrutinize heavily :)The code for
new-clean'scleanActionis mostly a direct copy from that ofclean, but in addition, it also removesdist-newstyleandcabal.project.local, if they exist.I'm not sure if the flags for
cleanall make sense fornew-clean. For instance,cleanhas a--save-configureflag to allow the user to avoid removing thedist/setup-configfile. Does this make sense fornew-clean?Fixes #2957.