SFGUI CMAKE trouble shoot

When using CMake, remove C:\DEV\PROG\Git\bin from path variable.
Because it contains sh.exe, and it messes up setup.

//ERROR:
CMake Error at cmake/Modules/FindSFML.cmake:306 (message):
  Could NOT find SFML (missing: SFML_GRAPHICS_LIBRARY SFML_WINDOW_LIBRARY
  SFML_SYSTEM_LIBRARY)
Call Stack (most recent call first):
  CMakeLists.txt:21 (find_package)

SOLUTION TO TRY: Environment variable setting:
SET:
SFML_ROOT     == C:\DEV\SDK\GAME_DEV\SFML\SOURCES\SFML-2.3.2\src\SFML
SFML_INCLUDE_DIR == C:\DEV\SDK\GAME_DEV\SFML\SOURCES\SFML-2.3.2\include
SFML_GRAPHICS_LIBRARY == C:\DEV\SDK\GAME_DEV\SFML\SOURCES\SFML-2.3.2\src\SFML\Graphics
SFML_WINDOW_LIBRARY   == C:\DEV\SDK\GAME_DEV\SFML\SOURCES\SFML-2.3.2\src\SFML\Window
SFML_SYSTEM_LIBRARY   == C:\DEV\SDK\GAME_DEV\SFML\SOURCES\SFML-2.3.2\src\SFML\System
//Maybe GRAPHICS,WINDOW,SYSTEM are relative paths to SFML_ROOT?

We are getting closer. Looks like freetype dependency is missing... I never recall having to setup freetype
when getting SFML to work. However, I did specify it in the build options for SFML and it just...
Magically worked.
Here is screen shot of my SFML linker settings. Notice the freetype.

Found freetype in SFML source folder here:
C:\DEV\SDK\GAME_DEV\SFML\SOURCES\SFML-2.3.2\extlibs\libs-msvc\x64

But... These are .lib files,  not .a files... I am worried.
.lib == windows
.a   == linux
From my understanding.Well, give it a shot.

CLOSER! But for some reason:
SFML_GRAPHICS_LIBRARY
SFML_WINDOW_LIBRARY
SFML_SYSTEM_LIBRARY
Are missing?? When I already set the environment variables for those.
And I can successfully echo it in the command prompt via:
$ echo %SFML_GRAPHICS_LIBRARY%

AH!
This post: http://sfgui.sfml-dev.de/forum/topic256-sfgui-doesnt-seem-to-work-with-sfml-21.html

Makes mention of the "advanced" tab. For some reason the flags I specified on command line were not picked up by CMAKE.

 Not sure what to do about the DEBUG libraries, since I don't have them. But hopefully I can omit them and be alright.
After hitting "GENERATE". I get lots of errors like this:

I think maybe I need to point to the sub-folder that contains the .h and .cpp files.
Editing SFML_GRAPHICS_LIBRARY, SFML_WINDOW_LIBRARY, SFML_SYSTEM_LIBRARY
to reflect this.

Actually.. Think those vars are good. Need to research the error:
"Targets may link only to libraries."

  Ah... Instead of using the SOURCE files... I need to use the compiled source.
I have a folder of offical cmake builds of SFML that I can reference for that:

 

Wonder if there is any chance that the freetype.a file exists in same folder.
Because the freetype.lib file scares me.
YES! It is here... Probably should change freetype to this path:
C:\DEV\SDK\GAME_DEV\SFML\OFFICIAL_COMPILATIONS\SFML-2.3.2\GCC_TDM_SJLJ_32BIT\lib\libfreetype.a
Also.. The .jpeg library was pointing to a .dll file in my JAVA installation folder... Yeah... That sounds
sketchy too. Fixed that as well. Here is the screen shot of the fix:


Okay... Configure and Generate...

Wow. Everything worked. At it did it all in a second.
I thought fancy progress bar stuff was going to happen...
Now what??

Time to reference more of the documentation:
http://sfgui.sfml-dev.de/p/docs/guide/installing

I am guessing since I have MinGw path in my environment variables...
CDing into my jmBuild directory and running mingw-make should be enough.
IT IS!


Looks like the end result failed on me however.
Maybe I need to un-reference anything from the SFML sources and
be referencing the build of SFML in my configurations?

Wait... Am I using the correct gcc compiler version?
The version in the code blocks executable directory would be the wrong version.
Code blocks uses 4.7.1 which is not compatible with SFGUI.
I downloaded 4.8.1 of MinGw / gcc from source forge... Check my variables...


Taking guess... CMAKE build type filled in to be == "RELEASE"
https://github.com/BIC-MNI/minc-toolkit/issues/28

error: '_hypot' was not declared in this scope

Getting an error about _hypot not declared in this scope...
Seems to be a GCC bug.
https://github.com/g-truc/glm/issues/300
QUOTE:

This is a GCC issues with no apparent workaround on GLM side. Use -D__NO_INLINE__ or edit math.h as a workaround. Closing.
Thanks,
Christophe
END_QUOTE

Found location of Math.h:
C:\MinGW\lib\gcc\mingw32\4.8.1\include\c++\tr1\Math.h

Looks like it also requires editing of file "cmath" within the same folder.


9Months ago on stack overflow:
http://stackoverflow.com/questions/29450016/o1-2-3-with-std-c1y-11-98-if-cmath-is-included-im-getting-error-hypo
QUOTE:

To avoid any further speculation, and downright bad suggestions such as using #if 0, let me give an authoritative answer, from the perspective of a MinGW project contributor.
Yes, the MinGW.org implementation of include/math.h does have a bug in its inline implementation of hypotf (float, float); the bug is triggered when compiling C++, with the affected header included (as it is when cmath is included), and any compiler option which causes __STRICT_ANSI__ to become defined is specified, (as is the case for those -std=c... options noted by the OP). The appropriate solution is not to occlude part of the math.h file, with #if 0 or otherwise, but to correct the broken inline implementation of hypotf (float, float); simply removing the spurious leading underscore from the inline reference to _hypot (float, float), where its return value is cast to the float return type should suffice.
Alternatively, substituting an equivalent -std=gnu... for -std=c... in the compiler options should circumvent the bug, and may offer a suitable workaround.
FWIW, I'm not entirely happy with MinGW.org's current implementation of hypotl (long double, long double) either; correcting both issues is on my punch list for the next release of the MinGW runtime, but ATM, I have little time to devote to preparing this.
ENDQUOTE:

Wait... Looks like I am looking at the wrong files:
Need to be looking at:
c:\mingw\include\math.h

See the spurious underscore that the MinGW contributor was speaking of? Remove it.

Here is my solution in Math.h
////////////////////////////////////////////////
/* 7.12.7.3  */
//BUGFIX: See stack overflow for hypot error.
//http://stackoverflow.com/questions/29450016/o1-2-3-with-std-c1y-11-98-if-cmath-is-included-im-getting-error-hypo
extern double __cdecl hypot (double, double); /* in libmoldname.a */
extern float __cdecl hypotf (float, float);
#ifndef __NO_INLINE__
__CRT_INLINE float __cdecl hypotf (float x, float y)
{ return (float)(hypot (x, y)); } //JMIM COMMENT: Fixing bug in MINGW.
#endif
extern long double __cdecl hypotl (long double, long double);
////////////////////////////////////////////////

Now trying to build SFGUI again... Getting these errors:
undefined reference to:
'__gxx_personality_sj0'
'_Unwind_SjLj_Register'
'_Unwind_SjLj_Resume'
'_Unwind_SjLj_Unregister'
 I guess the different libraries were compiled using different types of exception handling.
And this has lead to incompatibilities.
http://stackoverflow.com/questions/7751640/undefined-reference-to-gxx-personality-sj0

 Taking a guess:


Added -lstdc++ to compiler flags... Maybe this will help??
NOPE! Gets to 60 something percent and goes BOOM! On me with lots of errors like last time.

Above screen shot of my second attempt. Think I was just adding the flag wrong!

Weird... Seems to be starting me off from where I left-off...
Rather than starting at zero percent:



It is 9:22PM on Sunday... Might want to pack up soon...

Note: it is "mingw32-make" not "mingw-make" on the command line.
Is there are mingw64-make???
Because I am on a 64bit operating system, compiling 64 bit libraries... Wait... No... SFML is 32bit...
Is SFGUI that I am using 64bit? Could any of that be causing problems?

Still blowing up at 64%.

Trying a lot of stuff from here:
http://stackoverflow.com/questions/11783932/how-to-add-linker-or-compile-flag-in-cmake-file
But still no luck...

More research. Seems beyond me.
http://www.qtforum.org/article/29890/qt-4-6-linking-problem.html

I don't want to have "not made here syndrome". But at this point... Seems like making my own
simple UI library will be easier than this.
I just don't know enough to use Awesomium or SFGUI it seems.

Now 9:55PM.

SFML provides most of what I will need to make a GUI library.
GUI should probably be a distinct library from my game project.


Well, I want a flat file system... But... I will have to think about organization.