Re: tapfiles double-colon rule

[Ralph Lange via Core-talk <core-talk at aps.anl.gov>]

Hi Andrew,

On Tue, 21 Apr 2020 at 18:20, Johnson, Andrew N. <anj at anl.gov> wrote:

On Apr 21, 2020, at 5:23 AM, Ralph Lange via Core-talk <core-talk at aps.anl.gov> wrote:

NB. Ran into a minor bug in make (4.2.1): if you're defining multiple grouped target rules (that use the '&:' separator), make creates bogus warnings about "overriding recipe for target '&'" - the rules work fine, though.

Are you sure that grouped targets are actually available in 4.2.1? They aren’t mentioned in the info pages for my 4.2.1 installation at all, but I did find documentation for them in the online docs for version 4.3. That warning message looks like it thinks the rule is also building a target called ‘&’ and the rules might still work anyway. I probably read about these when 4.3 came out but I don’t think we can use them in Base for a few years.

I was checking with the examples from the online documentation on my 4.2.1 installation - will double-check and probably do a workaround.

Thanks for looking at my PR and making those changes. I didn’t think the specific TAPFILES.t (and JUNITFILES.t) variables would be necessary for those static pattern rules, given that the %.t source files wouldn’t exist so Make would look for some other way to create the %.tap files. I assume it didn’t like it though, your change is fine (and maybe faster even if it’s not required).

A bit weird, yes. I was getting warnings that (my added tap-generating) rules were overwritten by those rules, followed by make failures because it didn't find a way to generate the .tap files. (As it just had overwritten the rule that would tell it how.)

Adding the specific variables was fixing that behavior. In the JUNITFILES case I think it is required, as despite .tap files existing, I don't want .xml to be generated by converting them. Google Test is directly writing .xml and .tap reports.

Please comment on my new .tests-failed $(TEST_FAILURE_FILE) and $(PROVE_FAILURE) mechanism – see the changes in CONFIG_BASE and RULES_TOP for the key parts of that. It could be expanded or changed, it’s basically a way for the runtests and test-results targets to save the test status of a series of tests along with a message, and have those messages output at the end of the build along with returning a success/failure statue. Currently $(PROVE_FAILURE) just captures stdout from $(PROVE) and appends it to the $(TEST_FAILURE_FILE) (which is stored under $(TOP), I will need to merge the files from all submodules in the 7.0 branch), but it looks like we could put more functionality in here if we wanted to.

Works as advertised for me. Also simple and flexible enough to be extended as we need it. Fine!

Cheers,
~Ralph