[m-rev.] for post-commit review: a start on getting type repn info from .int files

[Zoltan Somogyi]

2021-07-26 14:48 GMT+10:00 "Peter Wang" <novalazy at gmail.com>:
>> > First, should we change  tools/bootcheck so that --test-params is the default?
>> > Julien and I both apparantly forgot its existence; we believed that the
>> > presence of --intermod-opt in Mmake.stage.params would cause the tests
>> > to be done with --intermod-opt, when that is true ONLY with --test-params.
>> > I propose that we should.
>> 
>> Agreed.
> 
> Agreed. I forgot about --test-params as well, because I've long used a
> wrapper script that always passes --test-params.

I have just changed bootcheck to make --test-params the default,
but --test-params is still accepted as an option (as is --no-test-params).

>> I think they should be moved to separate tests directory regardless of
>> which of the above is chosen; supporting two different ways of handling
>> the tests in the same directory just complicates the test
>> infrastructure. Doing that should allow for (1), which seems to be
>> the simpler of the three options.
> 
> I agree. "Anything" to simplify our makefiles.
> 
>> 
>> With regard to the way the compiler prints out error messages during
>> dependency generation: I assume that its current behaviour is just
>> for historical reasons?  (i.e. collecting and printing them all at
>> once would be the more desirable behaviour anyway)
>> 
>> > Third, for the other test cases in tests/invalid*, i.e. the ones for which
>> > making dependencies works without any errors, should (1) we make the
>> > dependencies, and then use the <module>.ints mmake targets, and
>> > maybe related targets, to make the required dependencies, or
>> > (2) just execute mmc --make-short-interface/--make-interface commands
>> > directly in the relevant mmake rules? I would prefer (1).
>> 
>> I also prefer 1.
>> 
> 
> Also 1.

OK, I will follow both of those paths.

>> No idea for my part.  Peter, does your memory stretch back
>> that far?
> 
> The exit status of the first invocation is ignored:
> 
>     -$(MCM) $@
> 
> The second invocation forces a rebuild:
> 
>     if $(MCM) -r $@ > /dev/null 2>&1
> 
> which overwrites the .err files from the first invocation.

Yes, I know. I was asking not about the exit statuses or the .err files,
but output to stdout and stderr. There must be some such output,
or the redirects to /dev/null wouldn't be there. Or are the redirects
not necessary after all?

Zoltan.