In some scenarios the hierarchy of schemas may be very interconnected
and redundant parsing of the same imported files is a huge performance
overhead for code generation (this change showed 20x improvement when
compiling a sample set of ~900 interconnected schemas).
When compiling multiple .bond files at once, the `--jobs=[NUM]` command
line option can be used to specify how many jobs should be run
concurrently. When used without arguments, the default is to run as many
jobs as there are processors. The option also accepts negative numbers
to specify fewer jobs than the number of processors. Often the optimal
performance is achieved by leaving one or more cores for other processes
on the machine.
Made the following changes for the open source AppVeyor plan which
runs on very slow and memory limited VMs:
- Limit ghc heap size to 192MB when installing dependencies
- Use `appveyor DownloadFile` instead `Start-Download`
- Download Boost in the smaller 7Zip format
- Cache cabal sandbox and boost download
- Disable C++ build
The cabal version 1.20+ was required only for the --required-sandbox
flag. However since the make files are setting up the sandbox we know
that we are always building using sandbox. The current Haskell Platform
comes with cabal 1.18 so this way installing cabal update is not needed.
This change fixes a bug in lookup of an unqualified symbol from an
imported schema file when one of the files is using a language specific
namespace. Language specific namespaces are not documented and their
use is not recommended, but the compiler supports them for backward
compatibility with legacy code.
The bug in the parser caused it to interpret any default value starting
with the letter L as a string literal, resulting in a parsing error for
constructs like:
struct Foo
{
0: Verbosity verbosity = Low;
}
CMake Visual Studio generator translates add_custom_command into a batch
file embedded in Visual Studio project. Batch files have problems with
paths that contain non-ascii characters because they are limited to DOS
encoding. It so happens that cabal is quite likely to be installed in
such a path because by default cabal installs into a directory under
%APPDATA% which contains user name. As a workaround we execute cmake
scripts as a custom commands and depend on CMake cache to get access to
variables set during configuration. This way embedded batch files are
free of non-ascii characters.