Fix 'check' target without tidy

If configure didn't find tidy, it would assign an error message to the TIDY variable. Fix the logic of STEPMAKE_OPTIONAL_REQUIRED to leave a constant 'false' in the variable if an optional program is not found. This can be easily checked and has the advantage that it is guaranteed to fail if executed.

[lemzwerg, 2019-10-25 17:05:20]

LGTM

[Dan Eble, 2019-10-25 20:10:08]

Thanks for this.  Seeing a warning message for an optional program bothered me,
but addressing it was out of my depth.

What do you think about using "false" rather than "no" if the program is not
found?  That would be more defensive because if "$(TIDY) ..." is executed as
"false ...", we can be pretty confident that it will fail consistently, but some
developer might have a program called "no" in the path that would do something
unexpected.

[hahnjo, 2019-10-26 08:48:40]

Use 'false' as negative value

[hahnjo, 2019-10-26 08:51:34]

On 2019/10/25 20:10:08, Dan Eble wrote:
> Thanks for this.  Seeing a warning message for an optional program bothered
me,
> but addressing it was out of my depth.

This is not about removing the warning message that an optional dependency
cannot be found, that is fine in my opinion. The problem is that the check in
GNUmakefile.in for an empty value was wrong and it tries to execute tidy despite
not being there.

> What do you think about using "false" rather than "no" if the program is not
> found?  That would be more defensive because if "$(TIDY) ..." is executed as
> "false ...", we can be pretty confident that it will fail consistently, but
some
> developer might have a program called "no" in the path that would do something
> unexpected.

Good idea, I've updated the patch.

[Dan Eble, 2019-10-26 12:40:58]

On 2019/10/26 08:51:34, hahnjo wrote:
> This is not about removing the warning message that an optional dependency
> cannot be found, that is fine in my opinion. The problem is that the check in
> GNUmakefile.in for an empty value was wrong and it tries to execute tidy
despite
> not being there.

Well, for that I must apologize.  I thought I had tested that case, but
obviously I did something wrong.

[Dan Eble, 2019-10-26 14:57:32]

I don't have time right now to test that this still works when tidy is
installed, but since it's blocking others, I see no problem with pushing it to
staging.

[dak, 2019-10-26 16:52:51]

On 2019/10/26 14:57:32, Dan Eble wrote:
> I don't have time right now to test that this still works when tidy is
> installed, but since it's blocking others, I see no problem with pushing it to
> staging.

It's not just that there "is no problem".  Without working test procedures, the
state of this patch will not change to "push" anyway, so until testing gets
fixed, patches to fix patching cannot wait for testing.