FW: darcs patch: Add extern flag to avoid multiple
claus.reinke at talk21.com
Mon Sep 8 07:14:21 EDT 2008
| What is the correct make target to get rid of all such generated files?
| Starting from a fresh tree everytime or searching for files manually
| don't sound realistic - there must be some support in there for
| getting rid of all generated left-overs (distclean presumably leaves
| them there for source distributions).
>- Adding files to remove when you say 'make clean' is manual, and hence error prone
yes. This is slightly improved if generated files end up in a separate
directory, as they do with Cabal (though that then requires hacks
to preserve generated source?-).
>- When you 'darcs pull' a file that *used* to be removed is no
>longer removed because it is no longer generated. (Some people
>recommend 'make distclean' before pulling, but that seems extreme.)
I always do 'make distclean' before pulling, simply because I've
been bitten too often. But recently, I still get bitten, so this isn't
extreme enough! It is really no fun at all that every single time I
try to build ghc head on windows, I run into issues that take a
week or more to settle down. And since the buildbot builders
seem to start from scratch, and ghc developers pull more often
than I, people here often don't know what I'm talking about.
In theory, 'make' should take care of this - if there are files it
doesn't know about for cleaning, those files shouldn't matter
for building, and if there are files that 'make' would use for
building, then it should also notice if they need rebuilding or
cleaning. In practice, ghc has slid further and further into a
'make' system that doesn't really know what it is doing, asking
the user to decide when to do 'make' (which rebuilds lots of
stuff that wasn't changed) or 'make distclean;make' (because
the change was too difficult for this 'make' to notice').
>The obvious solution to both is to somehow offer 'make superclean',
There is a 'maintainer-clean', which might do the trick at the
moment because it is out of date and still assumes that the
generated sources are next to their templates, so it might
remove the outdated generated sources. But that won't help
if the target isn't kept up to date.
>which removes every single file and directory that is not in the
>source repo. That is right-by-construction, and stays right
>regardless of changes. I don't know how to implement it
>though -- and of course any sort of automated 'rm' is anxious-making.
What I tend to try is 'darcs-all whatsnew -l >../rm-candidates'
(with selective removal of candidates), but '.darcs-boring' isn't up
to date (though better than it used to be, I think):
- it still masks generated sources/parsers in directories where
they should no longer exist (and where they do cause trouble
- it doesn't mask all sub-repo dirs (such as libraries/syb)
- it doesn't mask 'gmp/' - shouldn't that either be cleaned
or be masked?
Using this, I found some files and directories that really should
have been disappeared by 'make distclean'.
>Perhaps the easiest thing is to start with a fresh link-tree.
>That's easy and fast -- but does not work on Windows.
So your recommendation for me is to 'darcs get;darcs-all
get --extra' every time I want to 'pull' & 'make' on windows?
Suddenly, 'make maintainer-clean; darcs-all pull;..;make'
doesn't sound extreme at all.
I know this kind of thing is difficult to keep working for a
system as complex as ghc, and it does seem to improve
occasionally, but it still seems far from optimal.
More information about the Cvs-ghc