Gut Build System
Neil Mitchell
ndmitchell at gmail.com
Sat Mar 6 05:13:47 EST 2010
>>> http://chadaustin.me/2010/03/your-version-control-and-build-systems-dont-scale-introducing-ibb/
>>
>> This link is crazy. He's abusing big O notation, complaining about
>> constant factors (Python starting up) then suggesting he needs to
>> reduce the algorithmic complexity. He also forgets to factor in
>> O(time-of-ssd-drive), which probably divides O(time^2) to get O(who
>> cares). There is a valid point at the bottom that a null build should
>> be quick, and I agree, but I think it's far more important to get fast
>> rebuilds - anything less than a second on a null rebuild isn't
>> relevant.
>
> Yes, the first part of the article is hideous. But I liked the idea
> of updating the meta information in the background. I don't think
> that is very portable or even needed for most kinds of projects, but
> it is something to keep in mind in, that this is something a build
> system might want to support one day.
Yes, the idea of accumulating meta information sounds cool. But it's
an optimisation, and before optimising, profile :-) I am dubious about
the need for this trick given git is lightening fast, and must do a
complete timestamp check on O(files). Note that the benchmark he gives
of running git is probably suspect - if he did it twice the disk cache
would probably kick in and be lightening fast.
I also think a better solution to the problem would be to have
directory timestamps, noting when anything (recursively) in a
directory changes. If these were put in the file system (or faked by
some sort of watching deamon) then you could write an O(1) build
system without turning the build system in to a persistent service,
which is easier.
>>>> Dependencies among files I anticipate could be treated as a type.
>>
>> I'd be very surprised if that was possible.
>
> Not possible, or just too hard to use?
Not possible, I think. Foo.hs depends on the *.hi of each import. i.e.
the dependencies depend on the file contents. Either you'd need to
permit some kind of hole (in which case the dependencies aren't
statically checkable), or you'd need to lift the contents of Foo.hs in
to the type system. Either way, I don't see how types can track
everything, and I don't see what the benefit is.
If you were willing to specify all the dependencies statically, like
in a Makefile, this probably would be possible. But please, don't
reinvent make in the type system!
Thanks, Neil
More information about the Cvs-ghc
mailing list