Yes, the exact sequence was
sudo make install.
(I understand that specifying winuae-cpu may no longer be necessary as it looks as though it is now the default setting as of the last or second last dev update).
I have previous downloaded versions of Hatari in folders, eg, 'hatari-1.8.0' and 'hatari-1.9.0' and now the devel version in folder 'hatari-dev', When I compiled V1.9.0 it obviously overwrote the installed executable of V1.8.0 with V1.9.0, but continued to use my original saved .cfg file, wherever that is normally kept. When I compiled 1.9.x dev, it again overwrote the previous executable, but on first running the screen settings did not appear to match the way they were set in the F12 / Atari screen / Hatari screen menus, and it seemed that I had to deliberately set some of them in reverse to force the screen behaviour I wanted.
Don't worry about this too much at the moment: Over the weekend I will try to play with it more and see if I can pin down some specific, consistent misbehaviour that I can tell you about. I know there is nothing worse than a vague bug report.
Edit: OK, here's something you can investigate and maybe reproduce.
Using only the F12 menus (not command line switches) and with Hatari running as an emulated 2MB ST (confirmed by the info bar at the bottom of the screen, in mono fullscreen mode...)
... I find that if I set 'TT/Falcon resolution locked', the ST/STE resolution is locked (but the checkbox for 'ST/STe resolution locked' remains clear).
If I uncheck 'TT/Falcon resolution locked', then ST/STe resolution is unlocked and the emulated screen expands to fill the whole physical screen. Does this happen for you?