At my last job we ported the build scripts to FAKE and afterwards many people (everyone?) felt that it had been a mistake. There were probably a few reasons for this:
1. we wanted to split the build scripts across multiple files, as we had multiple builds sharing common parts of a build process, and the only way of doing that with F# seemed to be writing a bunch of scripts that #load-ed each other. This was unpleasant.
2. at the time FAKE tried to kill processes it launched at the end of a build, but this was not implemented terribly well, so if you ran multiple FAKE builds in parallel on the same Windows box there was a fair chance they'd start trying to murder each other, and you'd end up having builds fail for no reason. This was fun to debug. IIRC FAKE was trying to track processes using process ids, but these get recycled...
3. we weren't using F# for anything else in the business, so having the build scripts in F# meant even less people wanted anything to do with them.
Here's a Q&A with myself that I wrote at the time about the #load-ing stuff:
Q1. do you recommend constructing build systems out of many .fsx scripts that #load each other?
A1. no. the #load mechanism of f# scripts is lamentable, in that it does not like you #load-ing something twice, yet no mechanism like #pragma once or #define / #ifndef is provided.
Q2. couldn't you work around that problem by not making your "library" .fsx scripts #load anything, and write a top-level "main" .fsx script that #loads all transitive dependencies exactly once in the correct order?
A2. yes. yet that sounds strangely similar to what you might wish a build system to do for you.
edit: and now I'm reminded of something else, that isn't to do with FAKE, just another fun windows parallel build interaction thing: you run a couple of builds on a windows box using jenkins. in each build, you use msbuild to compile some visual studio project. msbuild launches some mspdbsrv process that is cleverly shared between msbuild processes. then the first jenkins build finishes, and jenkins cleverly kills all processes launched by the build, including mspdbsrv, while the second build is still using it. hurray for interactions between two different pieces of clever software! at least this one is fixable by setting environment variables telling msbuild not to do this once you figure out what is going on.
1. we wanted to split the build scripts across multiple files, as we had multiple builds sharing common parts of a build process, and the only way of doing that with F# seemed to be writing a bunch of scripts that #load-ed each other. This was unpleasant.
2. at the time FAKE tried to kill processes it launched at the end of a build, but this was not implemented terribly well, so if you ran multiple FAKE builds in parallel on the same Windows box there was a fair chance they'd start trying to murder each other, and you'd end up having builds fail for no reason. This was fun to debug. IIRC FAKE was trying to track processes using process ids, but these get recycled...
3. we weren't using F# for anything else in the business, so having the build scripts in F# meant even less people wanted anything to do with them.
Here's a Q&A with myself that I wrote at the time about the #load-ing stuff:
Q1. do you recommend constructing build systems out of many .fsx scripts that #load each other?
A1. no. the #load mechanism of f# scripts is lamentable, in that it does not like you #load-ing something twice, yet no mechanism like #pragma once or #define / #ifndef is provided.
Q2. couldn't you work around that problem by not making your "library" .fsx scripts #load anything, and write a top-level "main" .fsx script that #loads all transitive dependencies exactly once in the correct order?
A2. yes. yet that sounds strangely similar to what you might wish a build system to do for you.
edit: and now I'm reminded of something else, that isn't to do with FAKE, just another fun windows parallel build interaction thing: you run a couple of builds on a windows box using jenkins. in each build, you use msbuild to compile some visual studio project. msbuild launches some mspdbsrv process that is cleverly shared between msbuild processes. then the first jenkins build finishes, and jenkins cleverly kills all processes launched by the build, including mspdbsrv, while the second build is still using it. hurray for interactions between two different pieces of clever software! at least this one is fixable by setting environment variables telling msbuild not to do this once you figure out what is going on.