0f5d93e0c3
* Initial commit with create-daml-app master * Include create-daml-app in build rule * Make daml.yaml a template in version and project name * Remove git attributes * Remove license and azure config * Remove scripts * Don't overwrite config files in build rule * Template version numbers in package.json, to be replaced by the assistant * Rename to package.json.template changelog_begin changelog_end * Add copyright headers * Do template substitutions in all .template files And don't special case daml new create-daml-app (so it treats it as a regular template). * Add create-daml-app to integration tests * Remove WIP warning * Move towards setup that works on head * Make local copies of the TS libs in the templates tarball * Hardcode project name for now * Use isExtensionOf * Remove service worker * remove robots.txt (don't even know what it is) * Revert "Make local copies of the TS libs in the templates tarball" This reverts commit 1289581fb4a82af3ab534baf978a2c6ed895d538. * Retemplatize TS lib versions. For head builds these will be installed using npm * Remove daml/ledger from resolutions for daml-ts * Comment about test secret * Remove special create-daml-app assistant command and test that won't work anymore * Remove redundant imports and export * Remove old create-daml-app tests * Remove yarn.lock * Clean up integration test (just daml new and build atm) * Add daml/ledger as a resolution for daml-ts * Remove top level package.json * Update daml.js version * Use new import scheme for generated TS * Update readme with new codegen and build steps * Use start-navigator in daml.yaml * Increase a couple of timeouts in tests (either sandbox or TS lib is a bit slower?) * Update GSG intro with new build steps * Remove daml2ts -p flag and --start-navigator flag from GSG instructions * Don't use start-navigator flag in ui tests * Temporary readme describing how to manually test the create-daml-app template * Update code samples in app arch section of GSG * Update code samples in testing doc * Remove copied create-daml-app code * Indent docs markers to be more subtle * Update visible code in Messages (after) section This needs to be kept up to date properly somehow. * Update text to useLedger * Restore code/ui-before copies until the Bazel magic is figured out We need to make the template code a dependency in the Bazel rule as otherwise we can't find the files in the docs build. * Update create-daml-app/readme and make templates/readme more detailed * Use jsx comments for docs markers so they don't show up in the app |
||
|---|---|---|
| .github | ||
| .vscode | ||
| 3rdparty | ||
| bazel_tools | ||
| build-scripts | ||
| ci | ||
| compiler | ||
| daml-assistant | ||
| daml-lf | ||
| daml-script | ||
| dev-env | ||
| docs | ||
| extractor | ||
| ghc-lib | ||
| infra | ||
| language-support | ||
| ledger | ||
| ledger-api | ||
| ledger-service | ||
| libs-haskell | ||
| libs-scala | ||
| navigator | ||
| nix | ||
| oss-compliance | ||
| release | ||
| replacements | ||
| rules_daml | ||
| scala-protoc-plugins | ||
| templates | ||
| triggers | ||
| .bazelignore | ||
| .bazelrc | ||
| .dadew | ||
| .dockerignore | ||
| .envrc | ||
| .gitattributes | ||
| .gitignore | ||
| .hie-bios | ||
| .hlint.yaml | ||
| .mergify.yml | ||
| .scalafmt.conf | ||
| .sha256 | ||
| .watchmanconfig | ||
| azure-cron.yml | ||
| azure-pipelines.yml | ||
| BAZEL-bash.md | ||
| bazel-haskell-deps.bzl | ||
| BAZEL-haskell.md | ||
| bazel-java-deps.bzl | ||
| BAZEL-JVM.md | ||
| BAZEL.md | ||
| BUILD | ||
| build.ps1 | ||
| build.sh | ||
| CHANGELOG | ||
| CODE_OF_CONDUCT.md | ||
| CODEOWNERS | ||
| CONTRIBUTING.md | ||
| COPY | ||
| daml-logo.png | ||
| deps.bzl | ||
| dotfiles | ||
| fmt.sh | ||
| LATEST | ||
| LICENSE | ||
| maven_install.json | ||
| NOTICES | ||
| package.json | ||
| README.md | ||
| release.sh | ||
| report-std-change.sh | ||
| SECURITY.md | ||
| stack-snapshot.yaml | ||
| tsconfig.json | ||
| unreleased.rst | ||
| unreleased.sh | ||
| Upgrading.md | ||
| WORKSPACE | ||
| workspace_status.sh | ||
| yarn.lock | ||
Copyright 2020 Digital Asset (Switzerland) GmbH and/or its affiliates. All Rights Reserved. SPDX-License-Identifier: Apache-2.0
Welcome to the DAML repository!
This repository hosts all code for the DAML smart contract language and SDK, originally created by Digital Asset. DAML is an open-source smart contract language for building future-proof distributed applications on a safe, privacy-aware runtime. The DAML SDK is a set of tools to help you develop applications based on DAML.
Using DAML
To download DAML, follow the installation instructions. Once installed, to try it out, follow the quickstart guide.
If you have questions about how to use DAML or how to build DAML-based solutions, please ask them
on StackOverflow using the daml tag.
Contributing to DAML
We warmly welcome contributions. If you are looking for ideas on how to contribute, please browse our issues. To build and test DAML:
1. Clone this repository
git clone git@github.com:digital-asset/daml.git
cd daml
2. Set up the development dependencies
Our builds require various development dependencies (e.g. Java, Bazel, Python), provided by a tool called dev-env.
Linux and Mac
On Linux and Mac dev-env can be installed with:
- Install Nix by running:
bash <(curl https://nixos.org/nix/install) - Enter
dev-envby running:eval "$(dev-env/bin/dade assist)"
If you don't want to enter dev-env manually each time using eval "$(dev-env/bin/dade assist)",
you can also install direnv. This repo already provides a .envrc
file, with an option to add more in a .envrc.private file.
Windows
On Windows you need to enable long file paths by running the following command in an admin powershell:
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem' -Name LongPathsEnabled -Type DWord -Value 1
Then start dev-env from PowerShell with:
.\dev-env\windows\bin\dadew.ps1 install
.\dev-env\windows\bin\dadew.ps1 sync
.\dev-env\windows\bin\dadew.ps1 enable
In all new PowerShell processes started, you need to repeat the enable step.
3. First build and test
We have a single script to build most targets and run the tests. On Linux and Mac run ./build.sh. On Windows run .\build.ps1. Note that these scripts may take over an hour the first time.
To just build do bazel build //..., and to just test do bazel test //.... To read more about Bazel and how to use it, see the Bazel site.
On Mac if building is causing trouble complaining about missing nix packages, you can try first running nix-build -A tools -A cached nix repeatedly until it completes without error.
4. Installing a local copy
On Linux and Mac run daml-sdk-head which installs a version of the SDK with version number 0.0.0. Set the version: field in any DAML project to 0.0.0 and it will use the locally installed one.
On Windows:
bazel build //release:sdk-release-tarball
tar -vxf .\bazel-bin\release\sdk-release-tarball.tar.gz
cd sdk-*
daml\daml.exe install . --activate
That should tell you what to put in the path, something along the lines of C:\Users\admin\AppData\Roaming\daml\bin.
Note that the Windows build is not yet fully functional.
Caching: build speed and disk space considerations
Bazel has a lot of nice properties, but they come at the cost of frequently rebuilding "the world".
To make that bearable, we make extensive use of caching. Most artifacts should be cached in our CDN,
which is configured in .bazelrc in this project.
However, even then, you may end up spending a lot of time (and bandwidth!) downloading artifacts from
the CDN. To alleviate that, by default, our build will create a subfolder .bazel-cache in this
project and keep an on-disk cache. This can take about 10GB at the time of writing.
To disable the disk cache, remove the following lines:
build:linux --disk_cache=.bazel-cache
build:darwin --disk_cache=.bazel-cache
from the .bazelrc file.
If you work with multiple copies of this repository, you can point all of them to the same disk cache
by overwriting these configs in either a .bazelrc.local file in each copy, or a ~/.bazelrc file
in your home directory.
Haskell profiling builds
To build Haskell executables with profiling enabled, pass -c dbg to
Bazel, e.g. bazel build -c dbg damlc. If you want to build the whole
SDK with profiling enabled use daml-sdk-head --profiling.