Any ways detect files created by previously existing rules?

19 views
Skip to first unread message

manp...@gmail.com

unread,
Apr 13, 2017, 9:23:39 PM4/13/17
to Shake build system
Suppose we have a rule looking like this:

```
"*.asm.o" %> \out -> do
let src = dropExtension out
need [src]
cmd "as" [src] "-o" [out]
```

Removing corresponding .asm file will still leave compiled version around.

Now suppose this rule explains how to make .hi and .o files from .hs file and .hs file gets removed after compilation. ghc will still try to load it when using separate compilation if module with the same name still exists in a library.

manp...@gmail.com

unread,
Apr 13, 2017, 9:25:01 PM4/13/17
to Shake build system, manp...@gmail.com

How do I find and remove those files without reimplementing half of dependency tracking mechanism in a build system or without removing whole building tree?

Neil Mitchell

unread,
Apr 14, 2017, 8:21:10 AM4/14/17
to manp...@gmail.com, Shake build system
Hi,

Are you asking about this feature:
http://neilmitchell.blogspot.co.uk/2015/04/cleaning-stale-files-with-shake.html

Or is it something else?

Thanks, Neil

manp...@gmail.com

unread,
Apr 16, 2017, 7:08:00 PM4/16/17
to Shake build system, manp...@gmail.com
Hi Neil

That is pretty much exactly what I'm looking for. Thanks a lot!

Evan Laforge

unread,
Apr 16, 2017, 7:33:06 PM4/16/17
to manp...@gmail.com, Shake build system
Thanks for asking the question, and thanks to Neil for the answer. I
too have had the problem where ghc loads deleted modules because the
.hi and .o are still around, and just made it a habit to completely
delete the build directory whenever I renamed or deleted a module.
It's nice to know that there's a "correct" solution.

I worry a little bit that listFilesRecursive on a 1000 file build
directory after every build might be annoyingly slow. I suppose
Neil's repo must be much larger, and he was happy to use [FilePath]
and \\ instead of Set and Set.difference, and I know he cares about
performance, so maybe it's not a problem in practice. Also ghc itself
has problems with stale references (the hptSomeThingsBelowUs thing,
and I've seen the GHC API or even the linker get confused about a
missing symbol, so a complete reset still seems safest.

Actually now that I read the blog post more carefully, I think the
requirement to build everything when doing a --prune kind of kills it
for me. I have separate targets for debug, opt, profile, and test,
and building and I almost never want to build everything at once. Oh
well, still it's good to keep in mind for the future.

I suppose if I really wanted to get an incremental cleanup, I could
get darcs or git to tell shake which files were deleted, and then
figure out from the filename what outputs it would have created, and
then go delete just those. I guess it's not worth the effort over
just rebuilding from scratch, but if the repo were 10x larger I might
start considering things like that!

manp...@gmail.com

unread,
Apr 16, 2017, 7:41:46 PM4/16/17
to Shake build system
On Friday, April 14, 2017 at 9:25:01 AM UTC+8, manp...@gmail.com wrote:
> How do I find and remove those files without reimplementing half of dependency tracking mechanism in a build system or without removing whole building tree?

"it will build all files, then delete all stale files"

Hmm... Nope, not going to work. It fails to compile when there are stale files.

manp...@gmail.com

unread,
Apr 17, 2017, 6:58:14 AM4/17/17
to Shake build system, manp...@gmail.com

I think what I want is a relatively cheap way asking "Can we build this?". Not sure if it's possible though.

Reply all
Reply to author
Forward
0 new messages