check arguments re vignettes

[lgatto]

My typical workflow, after a set of changes, before committing consists of a build (with vignette) and a full check. As I have just build the vignette with the package, I wouldn't necessarily want to re-build the vignette and run the vignette code. But, the following

make check PKG=pRoloc VIG=1

1. builds the package with the vignette, as desired
2. checks the vignette with --no-build-vignettes but omits --no-vignettes

because of

CHECKARGS          := --no-vignettes --no-build-vignettes

ifeq (${VIG},1)
  BUILDARGS := $(filter-out --no-build-vignettes,$(BUILDARGS))
  CHECKARGS := $(filter-out --no-vignettes,$(CHECKARGS))
endif

Currently, I would need to

make build PKG=pRoloc VIG=1
make check-only PKG=pRoloc VIG=0

I would suggest a way to enable the described behaviour in one line, but I don't have a perfect solution. Any comments or suggestions?

[sgibb]

I have not any good idea.

Would it be useful to add a special target for this?

## e.g. in ~/.makerrc
check2: BUILDARGS := $(filter-out --no-build-vignettes,$(BUILDARGS))
check2: CHECKARGS += --no-vignettes
check2: check

make PKG=pRoloc check2

(We need a better name for it. Maybe we could replace the useless release target.)

[lgatto]

What about the following: the logic is that if the package was build, then there is not need to build/check the vignettes again.

In case I type

make check PKG=pRoloc VIG=1

the package gets build before checking. Then VIG=1 is applied to build and not to check. However, if I use

make check-only PKG=pRoloc VIG=1

then I explicitly check with full vignette.

Does that make sense?

[sgibb]

Would it be useful/safe to always use --no-vignettes if check was called directly after build? In this case we could simply modify the check target to:

check: CHECKARGS := $(filter-out --no-vignettes,$(CHECKARGS))
check: | build check-only

Another possibility would be to allow a third state for VIG:

• VIG=0: no vignettes in build and check
• VIG=1: vignettes in build and check
• VIG=2: no vignettes in check but in build

(we could change the order but this would break the current workflow of all users)

[lgatto]

I though about your second option, but I personally think it makes things more complicated. Option 1 seems to perfect to me, as long as it is documented.