- Buck uses symlinks under the hood in many places. We need to map that concept to the Windows equivalent throughout the codebase.
- Buck hardcodes the use of OS X/Linux file and path separators all over the place. This may be a poor software design choice, but it makes the code more readable in many circumstances, particularly in unit tests.
- Documentation becomes more work to maintain. For example, a nifty trick from the OS X/Linux command line, such as:
buck targets --type java_test | xargs buck testdoes not work on Windows, so that must be documented separately.
./bin/buckscript is written in Bash, so to support Windows, the equivalent would have to be maintained as a Windows Batch Script. Keeping both scripts in sync would be non-trivial. Alternatively, the run script could be written in a platform-independent language, such as Ruby, but that would require users to install an additional tool.
- It increases the surface area of what needs to be tested.
If Buck built itself using Buck, then every time a change was made to Buck's source, the commit would have to include a new Buck binary that included that change. It would be easy to forget to include the binary, difficult to verify that it was the correct binary, and wasteful to bloat the Git history of the repository with binaries that could be rebuilt from source. Building Buck using Ant ensures we are always building from source, which is simpler to verify.
Also, because Ant is a more mature build system than Buck, it has support for features that we have not had time to include in Buck yet, such as generating Javadoc, static analysis via PMD, Python unit tests, etc.
That said, as a sanity check, Buck is capable of building itself. Once you build Buck using Ant, you can re-build Buck using Buck by running
./bin/buck build buck.