Well my cmake ran almost the exact same, originally I though that the ARGC_V line coming back failed could be the culprit but the check for big medium or little endians returned successfully so I assume it should not be related. I just understand why a header file would redirect me to a .cmake file. I didn't use the -j 4 option, I am not sure what that does. One thing that I can definetly say looks different is the scanning for dependencies section of you log file following you make -j4 option. when I ran the make command I jumped right into

$ make
Scanning dependencies of target allegro_monolith
[ 0%] Building C object CMakeFiles/allegro_monolith.dir/src/allegro.c.obj

only that one, but this doesn't take into account the change to the cmake prefix directory you mentioned above.

EDIT:

Ok, I will try your edit. It is likely going to be a little bit of extensive work so I am going to get some sleep and get back on it a little bit earlier than this time tommororw.

Ok, So I was able to catch up with you. At first I was compiling with the Dev-CPP IDE but I thought I would take it to the command line. From here I am still getting the same error. It seems as though I am definitely have a problem linking. I modified my include path in both cases and still to end.

c:\Users\headgearxthree\Desktop\ALLEGRO>gcc -I C:\msys64\mingw64\x86_64-w64-mingw32\include altest.cpp
C:\Users\HEADGE~1\AppData\Local\Temp\ccJHTXW0.o:altest.cpp:(.text+0x26): undefined reference to `al_install_system'
C:\Users\HEADGE~1\AppData\Local\Temp\ccJHTXW0.o:altest.cpp:(.text+0x73): undefined reference to `al_create_display'
C:\Users\HEADGE~1\AppData\Local\Temp\ccJHTXW0.o:altest.cpp:(.text+0xd1): undefined reference to `al_map_rgb'
C:\Users\HEADGE~1\AppData\Local\Temp\ccJHTXW0.o:altest.cpp:(.text+0xf5): undefined reference to `al_clear_to_color'
C:\Users\HEADGE~1\AppData\Local\Temp\ccJHTXW0.o:altest.cpp:(.text+0xfa): undefined reference to `al_flip_display'
C:\Users\HEADGE~1\AppData\Local\Temp\ccJHTXW0.o:altest.cpp:(.text+0x108): undefined reference to `al_rest'
C:\Users\HEADGE~1\AppData\Local\Temp\ccJHTXW0.o:altest.cpp:(.text+0x114): undefined reference to `al_destroy_display'
collect2.exe: error: ld returned 1 exit status

c:\Users\headgearxthree\Desktop\ALLEGRO>gcc -I C:\msys64\mingw64\x86_64-w64-mingw32\include -c altest.cpp

c:\Users\headgearxthree\Desktop\ALLEGRO>dir
Volume in drive C is OS
Volume Serial Number is 426E-BDFE

Directory of c:\Users\headgearxthree\Desktop\ALLEGRO

11/27/2016 03:01 AM <DIR> .
11/27/2016 03:01 AM <DIR> ..
11/27/2016 02:36 AM 1,525 allegro.cpp
11/26/2016 05:08 AM 528 altest.cpp
11/27/2016 03:01 AM 1,354 altest.o
3 File(s) 3,407 bytes
2 Dir(s) 95,570,718,720 bytes free

c:\Users\headgearxthree\Desktop\ALLEGRO>

I can build an object file but thats it it just exits from compilation early. The -c flag is supposed to run compiler and link and I'm not sure what the gcc does on its own but it debugs in the IDE to give me the same problems. I've compiled with Dev-CPP before and it works. I don't see how I could have any undefined references unless the source code on github was bad.

Ok.

EDIT:
Do you mean during compilation time or before hand? I feel like if the command line is going to take that many arguments I would rather just start out by editing the lib paths under the directories tabs in the Dev-CPP IDE.

I though that is what I did when I ran make and make install. Do you have any suggestions on what flags to pass while doing that?

So would I use cmake as such...

cmake -DCMAKE_BUILD_TYPE=[Release | Debug | RelWithDebInfo | Profiling] and setting -DSHARED=[On | Off].

I know I already built to the C:\msys64\mingw64\x86_64-w64-mingw32\ directory. Did I not build all necessary dependencies then? Should I not now be complete and ready to compile with allegro?

Okay, I will inevitability want to use static, for the mean I wouldn't mind trying dynamic. Any suggestions on how to do so dynamically now so I can get a feel for how allegro looks when compiled, or any suggestions on how to build a static version? I thought that would be done.

I think I am confused about how the monolith library in implemented. I think I'm making progress.

C:\Users\headgearxthree\Desktop\ALLEGRO>gcc -L C:\msys64\mingw64\x86_64-w64-mingw32\ -l allegro_monolith -I C:\msys64\mingw64\x86_64-w64-mingw32\include altest.cpp
C:/TDM-GCC-32/bin/../lib/gcc/mingw32/5.1.0/../../../../mingw32/bin/ld.exe: cannot find -lallegro_monolith
collect2.exe: error: ld returned 1 exit status

C:\Users\headgearxthree\Desktop\ALLEGRO>

But, I'm not sure whats wrong here.

I'm just not sure what is going on I think I may have to rebuild this yet again. I found some remnants from the old folder where I was making it originally the "x64_64..." directory that we changed to "x86_64..." and in there I actually have a monolith.dll. But in my new installation directory the "x86_64" on I don't, so I'm guess I should have said yes last time to it. I am going to figure it out..

the one in the \bin sub directory is allegro_monolith-5.2.dll

and the one in the \lib sub directory is liballegro_monolith.dll.a

C:\Users\headgearxthree\Desktop\ALLEGRO>gcc -L c:\msys64\mingw64\x64_64-w64-mingw32 -l liballegro_monolith.dll.a -I c:\msys64\mingw64\x86_64-w64-mingw32\include altest.cpp
C:/TDM-GCC-32/bin/../lib/gcc/mingw32/5.1.0/../../../../mingw32/bin/ld.exe: cannot find -lliballegro_monolith.dll.a
collect2.exe: error: ld returned 1 exit status

Looks like its still not searching the file path I told it too. So I will work on this.

EDIT:

So I re-arranged my call to the compiler (i'm using the msys terminal here because I like it. I like be able to exit out and come back and use the arrow keys to recall commands. I want to build a utility like that for command prompt.)

headgearxthree@DESKTOP-PFLMU84 MINGW64 /c/users/headgearxthree/desktop/allegro
$ gcc altest.cpp -o altest -I c:\msys64\mingw64\x86_64-w64-mingw32\include -L c:\msys64\mingw64\x64_64-w64-mingw32 -lliballegro_monolith

headgearxthree@DESKTOP-PFLMU84 MINGW64 /c/users/headgearxthree/desktop/allegro
$ dir
allegro.cpp altest.cpp altest.exe altest.o gcc

headgearxthree@DESKTOP-PFLMU84 MINGW64 /c/users/headgearxthree/desktop/allegro
$ altest
-bash: altest: command not found

headgearxthree@DESKTOP-PFLMU84 MINGW64 /c/users/headgearxthree/desktop/allegro
$

Believe it or not I actually built a executable. Still doesn't work properly but is definitely an improve.) Command prompt would have let me execute it from the command line but that is a disappointment here.

So I guess I am a totally noob when it comes to this whole static/binary (monolith.etc) libraries concept. I personally don't understand why I can't just compile with the source code alone. And I do not understand why I need a .dll file to do something the .h file should already be doing. Is there anyway to build a allegro library that I can use from the command line with gcc that will build portable applications? And, will I have to keep a .dll with my project all the time or is that pessimistic of me to assume?

Are .dll's system dependent?

EDIT: So I dropped a copy of allegro_monolith-5.2.dll.a into the folder on my desktop where I was compiling from and now it doesn't give me the same error...

The error I was getting was less of a console error but rather a windowed notification saying that "the program could not start be allegro_monolith-5.2 is not installed on your computer, please reinstall this program an dtry again", However once I dropped a copy of this into that folder I no longer am getting that error but now I getting 3 pop-up windows that all state something similiar, one along the lines of libFLAC-8.dll, another libDUMB.dll and another for the same thing libfreetype-6.dll.

It does not appear as if I even have any of these on my c drive. I know the msys getting started page references them but only once and no build steps.

But I don't have any "allegro_monolith.dll" built. Last, time I went through the steps I cam out with a bunch of dll.s but none for allegro_monolith and the times before I was getting a allegro.dll but It was called "allegro_monolith-5.2.dll". I actually did get one last time in my bin file called "allegro-5.2.dll" in my bin folder along with a bunch of other .dll files. What exactly would static linking look like? Should I just start over? I think I am going to.

So when you say -lallegro_monolith.dll I should change that to -lallegro_monolith-5.2.dll or this is done automatically?

And, I would much rather build a static library. But, I can build both and both can exist simultaneously right??

Ok

Do you know what the general command line compilation command would look like if I were to compile statically from the source code alone if I were using micro soft vs native build tools?