mk/custom-settings.mk · c5a7ce02bc3cb360217af0748f298ffbfceaf2e8 · Reinier Maas / GHC · GitLab

Snippets Groups Projects

Forked from Glasgow Haskell Compiler / GHC

14983 commits behind, 3 commits ahead of the upstream repository.

9 years ago

Revert "Build system: don't create mk/are-validating.mk" · fa587316

Thomas Miedema authored 9 years ago

Summary:
This reverts commit aecf4a5f.

It turns out the Simons are relying on 'mk/are-validating.mk', see
D1307.

The workflow they are using is:
  * run ./validate
  * find a bug in the compiler
  * try to fix the bug, running 'make 1' (or 'make 2') repeatedly. Because
    of 'mk/are-validating.mk', this uses the same build settings as validate.
  * continue ./validate (--no-clean)

I suggested two alternatives:

  A. run 'make 1 Validating=YES' instead of 'make 1'

     Problem: when running `./validate --fast` or `./validate --hpc`
     instead of a normal `./validate`, validate sets ValidateSpeed and
     ValdateHpc in mk/are-validating.mk. You would for example have to run
     'make 1 Validating=YES ValidateSpeed=FAST' instead of 'make 1' to get the
     same build settings as `./validate --fast`, which is entirely too long and
     error prone.

  B. uncomment `#BuildFlavour=validate` in mk/build.mk, and include
     'mk/validate.mk'.

     Problems:
      * any other settings you have in build.mk will also get used.
      * the distinction between 'mk/validate.mk' and 'mk/build.mk' becomes less
        clear.
      * it is easy to forget to include 'mk/validate.mk'.
      * the build system again doesn't have access to the ValidateSpeed and
        ValdateHpc settings set by validate.

Neither of these two options is entirely satisfactory.

Reviewers: austin, bgamari

Differential Revision: https://phabricator.haskell.org/D1383

fa587316

Revert "Build system: don't create mk/are-validating.mk"

Thomas Miedema authored 9 years ago

Summary:
This reverts commit aecf4a5f.

It turns out the Simons are relying on 'mk/are-validating.mk', see
D1307.

The workflow they are using is:
  * run ./validate
  * find a bug in the compiler
  * try to fix the bug, running 'make 1' (or 'make 2') repeatedly. Because
    of 'mk/are-validating.mk', this uses the same build settings as validate.
  * continue ./validate (--no-clean)

I suggested two alternatives:

  A. run 'make 1 Validating=YES' instead of 'make 1'

     Problem: when running `./validate --fast` or `./validate --hpc`
     instead of a normal `./validate`, validate sets ValidateSpeed and
     ValdateHpc in mk/are-validating.mk. You would for example have to run
     'make 1 Validating=YES ValidateSpeed=FAST' instead of 'make 1' to get the
     same build settings as `./validate --fast`, which is entirely too long and
     error prone.

  B. uncomment `#BuildFlavour=validate` in mk/build.mk, and include
     'mk/validate.mk'.

     Problems:
      * any other settings you have in build.mk will also get used.
      * the distinction between 'mk/validate.mk' and 'mk/build.mk' becomes less
        clear.
      * it is easy to forget to include 'mk/validate.mk'.
      * the build system again doesn't have access to the ValidateSpeed and
        ValdateHpc settings set by validate.

Neither of these two options is entirely satisfactory.

Reviewers: austin, bgamari

Differential Revision: https://phabricator.haskell.org/D1383

Code owners

Assign users and groups as approvers for specific file changes. Learn more.

custom-settings.mk 258 B

-include mk/are-validating.mk

ifeq "$(Validating)" "YES"
include mk/flavours/validate.mk
-include mk/validate.mk
else
-include $(firstword $(wildcard mk/$(TargetPlatformFull)-build.mk) mk/build.mk)
endif

ifeq "$(BINDIST)" "YES"
-include bindist.mk
endif