mirror of https://github.com/digital-asset/daml.git synced 2024-09-20 01:07:18 +03:00

History

Andreas Herrmann 4b1438276c Update Bazel 2.1.0 --> 3.3.1 (#6761 ) * Upgrade nixpkgs revision * Remove unused minio It used to be used as a gateway to push the Nix cache to GCS, but has since been replaced by nix-store-gcs-proxy. * Update Bazel on Windows changelog_begin changelog_end * Fix hlint warnings The nixpkgs update implied an hlint update which enabled new warnings. * Fix "Error applying patch" Since Bazel 2.2.0 the order of generating `WORKSPACE` and `BUILD` files and applying patches has been reversed. The allows users to define patches to these files that will not be immediately overwritten. However, it also means that patches on another repository's original `WORKSPACE` file will likely become invalid. * `a948eb7255` * https://github.com/bazelbuild/bazel/issues/10681 Hint: If you're generating a patch with `git` then you can use the following command to exclude the `WORKSPACE` file. ``` git diff ':(exclude)WORKSPACE' ``` * Update rules_nixpkgs * nixpkgs location expansion escaping * Drop --noincompatible_windows_native_test_wrapper * client_server_test using sh_inline_test client_server_test used to produce an executable shell script in form of a text file output. However, since the removal of `--noincompatible_windows_native_test_wrapper` this no longer works on Windows since `.sh` files are not directly executable on Windows. This change fixes the issue by producing the script file in a dedicated rule and then wrapping it in a `sh_test` rule which also works on Windows. * daml_test using sh_inline_test * daml_doc_test using sh_inline_test * _daml_validate_test using sh_inline_test * damlc_compile_test using sh_inline_test * client_server_test find .exe on Windows * Bump Windows cache for Bazel update Remove `clean --expunge` after merge. Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>		2020-07-23 09:46:04 +02:00
..
bin	open-sourcing daml	2019-04-04 09:33:38 +01:00
libexec	Reenable isScoopEnabled (#5661 )	2020-04-22 10:08:12 +02:00
manifests	Update Bazel 2.1.0 --> 3.3.1 (#6761 )	2020-07-23 09:46:04 +02:00
.gitignore	open-sourcing daml	2019-04-04 09:33:38 +01:00
build.ps1	open-sourcing daml	2019-04-04 09:33:38 +01:00
README.md	Document the need for long file paths on Windows (#670 )	2019-04-24 18:21:56 +00:00
test.ps1	open-sourcing daml	2019-04-04 09:33:38 +01:00
VERSION	open-sourcing daml	2019-04-04 09:33:38 +01:00

README.md

Windows Dev-env

DADEW (DA Dev Env for Windows) is a tool, which can be used to setup a developer's environment on Windows machines.

How to use it?

First 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 you need to install your local DADEW environment by running:

.\dev-env\windows\bin\dadew.ps1 install

In this step a Scoop command-line installer is downloaded and configured. DADEW by default resides in User's home directory in dadew folder, usually C:\Users\<user-id>\dadew\. This is one-off action, unless you uninstall your DADEW environment.

To sync your local environment with required target environment's tools run:

.\dev-env\windows\bin\dadew.ps1 sync <.dadew file>

or just

.\dev-env\windows\bin\dadew.ps1 sync

in case of .dadew file in current location.

This will fetch all required tools, if not already available, and make them ready to use, but they will not be present on the $PATH yet.

To make all sync'ed tools present on the $PATH

.\dev-env\windows\bin\dadew.ps1 enable

To disable run:

.\dev-env\windows\bin\dadew.ps1 disable

$PATH environment variable is changed only in the current session, so DADEW needs to be enabled each time new powershell session is created in order to get tools available.

DADEW environment can be also uninstalled by running:

.\dev-env\windows\bin\dadew.ps1 uninstall

which will remove all tools physically from the workstation.

To get an absolute path of a binary provided by this dadew run:

.\dev-env\windows\bin\dadew.ps1 which <app>

Versioning

DADEW is versioned. You can check which version you are running by calling:

.\dev-env\windows\bin\dadew.ps1 version

In order to sync with required tools from specific repo (specific .dadew file) you need to have the same or newer version of DADEW installed. The minimum version which is required in order to perform a sync can be check by calling:

.\dev-env\windows\bin\dadew.ps1 required-version <.dadew file>

or just

.\dev-env\windows\bin\dadew.ps1 required-version

in case of .dadew file in current location.

How to build?

PS C:\> ./build.ps1

This will create dev-env-windows/dist/dadew-<VERSION>.zip file.

How to test?

DADEW is tested with use of Pester 4.

To check if Pester is available on your Windows machine and what version is installed run:

Get-InstalledModule -Name Pester

this will print Windows module details, including version:

Version    Name                                Repository           Description
-------    ----                                ----------           -----------
4.4.2      Pester                              PSGallery            Pester provides a framework for running BDD styl...

Version 4.x is required to run tests. If it's not present you can use simple script available at dev-env-windows/test/update-pester.ps1 to install required version of Pester.

Tests can be run using:

PS C:\> ./test.ps1