This is an update (sadly)....
I thought I was out of the water when allegro compiled following Polybios' step-by-step tutorial near the top of this thread. But....
I was unable to run programs because some entry point or something was wrong....
Not satisfied, I wasted two days figuring out what my problem really was. After all, I just compiled the allegro source on a win7 machine a few days ago flawlessly, here is the answer to my own question: How to install allegro 5.2.2 on a brand new, clean win10 machine:
1) Uninstall any MSVC++ redistributable back to before version 2010. (This prevents error s1023 - a well documented error with step 2)
2) Install DirectX from microsoft's official site.
3) Install mingw (mingw-get-setup.exe) from the mingw.org site. This is the older 32 bit version, but this is what worked for me. Install Choose everything but ada, objectivec, and fortran from the "basic setup" tab.
3.5) Add c:\mingw\bin and c:\mingw\msys\1.0\bin to the local system path by going to windows "system" (in control panel) and then clicking on "advanced settings" then clicking on "environment variables". This will keep the path any time you open a cmd window.
4) Install cmake (cmake-3.8.2-win64-x64.msi)
5) Get allegro-5.2.2.zip from http://liballeg.org/download.html . Unzip it into c:\ so that you end up with an allegro directory in the root c drive.
6) Also pull down sal.h at the bottom of the http://liballeg.org/download.html page. Put it in C:\MinGW\include. It turns out this is the file I was missing all along that allows allegro source to compile with DirectX, which is required.
7) Run cmake-gui.
a) Where is the source code: C:\allegro
b) Where to build the binaries: C:\allegro
c) Click on Configure - it makes a bunch of red statements
d) Change WANT MONOLITH to have a checkmark
e) Click on Configure again. All of the red should go away.
f) Click on Generate
g) exit Cmake.
7) Now edit into C:\allegro\cmakecache.txt
a) search on strerror_s
b) change to read:
//Have function strerror_r
//Have function strerror_s
This solves the problem that kills the compile at about 4% into it.
I think this is something that needs to be fixed, because after I run cmake, these values are set to 1, but then during compile there is an error because strerror is undefined. So something about the Cmake function that determines if strerror is defined is wrong.
8) in a dos cmd window, go to c:\allegro and type:
10) Finally, I added c:\allegro\lib into my local path environment variable so that I can run programs from any directory without worrying about the monolith .dll file.
So, in conclusion, the old mingw is perfectly adequate to compile the allegro5 source code, but there are two issues:
1) sal.h must be moved into the mingw\include directory, and
2) you have to fool the system into knowing that strerror is NOT defined.
Note also that there are numerous threads from the past that discuss the old problem that sal.h is needed to compile and resolve DirectX __in and __out missing items. And there are also threads about the known problem of the strerror_s!!!!
I hope this helps people in the future who just want to get their old, familiar allegro up and running on a win10 machine!!!
Thanks to everyone for all your great support and help. I love allegro, and I love the great community of people that have put so much into this!!!!!!
Thanks everybody for the help.