bug#42533: 28.0.50; srecode-utest-project test failing on macOS

[Eric Ludlam <ericludlam@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2290 bytes --]

Srecode loads in templates for various modes and applications into a map.
That particular test is verifying that the template associated with
srecode's template mode for the application 'tests' was found.

There are 2 templates for the 'test' application in:
 etc/srecode/proj-test.srt.
 etc/srecode/test.srt

Plus the template template:
 etc/srecode/template.srt

You can use:
M-x srecode-get-maps RET

to list all the templates discovered during srecode initialization on the
different platforms to see what is different.

The first part of the list are the mode specific template files.  After are
the application templates, and tests app should be in there.  (It was first
for me when I just tried it.)

What *might* be going on is ~/.emacs.d/srecode-map.el could be out of date
for whatever user/machine is running the test.  Discovering all the
templates is a bit slow, and srecode will rescan files that change but
doesn't know what files to scan based on file name, so the map and the
cache was meant to speed things up.  You can force a reload by passing
non-nil into srecode-get-maps.   The earlier test srecode-utest-map-reset
should do that, but as I look at the code, I don't see that it is.  In the
old cedet test suite, all the tests were run in a forced order w/out ert
(it wasn't around, or I didn't know about it when I was writing tests the
first time.)  Thus, there may be some order dependency I don't know about.

Hopefully this is helpful.  I don't usually have this much time to poke
around in emacs anymore.  You caught me on a good day. :)
Eric

On Mon, Aug 10, 2020 at 10:40 AM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> > I've tried to follow the logic of the test, but I'm failing to see how
> > the code diverges under Linux and Macos...  Perhaps Eric has some input
> > here?
>
> I spent about an hour on this last night, comparing what happens on
> Macos and Debian (where this test doesn't fail), and I wasn't
> successful.  This test is more of an integration test than a unit test
> in that it doesn't tell you much about where deep in the srecode
> machinery things go wrong, unfortunately...
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>

[-- Attachment #2: Type: text/html, Size: 3096 bytes --]