Do not use the lines above referencing ~/.emptyepsilon it has been far too long since I wrote code... I will post corrected code which uses the HOME envirnment variable to determine users homedir and such. I think I have it already but want to do some more extensive testing before I submit it to you. Again, I'm a troubleshooter rather than a programmer.
I'm a little suspicious of the completeness of the build. The uncompressed version weighs in at 5.5MB, about a 10th of the size of the Windows version. I'll see if I can get it to run on another Mac without SFML.
Windows version is mostly that big because of the resource files, so possibly the resources files are not packed in your build but can still be found on your system?
Hi - I'm trying to build EE on Linux - using EE source downloaded a week ago (Same for Serious Proton) and SFML 2.3.1. Building Linux Release using Code Blocks. Compiles beautifully until:
Compiling: src/modelData.cpp In file included from /home/gene/epsilon/EmptyEpsilon-master/src/modelData.cpp:1:0: /home/gene/epsilon/SFML-2.3.1/include/SFML/OpenGL.hpp:54:27: fatal error: GL/gl.h: No such file or directory compilation terminated.
Can't find this file anywhere. Think I've seen this before but I can't remember the solution. Any ideas??
Now - has anyone managed to build EE on FreeBSD ? There seems to be problems with the format of the SFML libraries. Apparently one cannot simply download the Linux version - the code compiled on Unix doesn't match up.
OK - figured I'd try Cmake - seems however, it's looking for certain "SeriousProton" files in EmptyEpsilon/src instead of SeriousProton/src. The first file I came across was "src/soundManager.cpp". just for giggles I created an empty soundManager.cpp file in EmptyEpsilon/src; Cmake found it. (Just wanted to be sure.)
Any ideas how to fix this one (I'm not a cmake person)
drwxr-xr-x 12 user wheel 31 Dec 2 12:21 EmptyEpsilon/ drwxr-xr-x 11 user wheel 22 Dec 2 10:39 SFML-2.3.1/ drwxr-xr-x 4 user wheel 7 Nov 23 08:15 SeriousProton/
CMake Error: CMake can not determine linker language for target: EmptyEpsilon CMake Error: Cannot determine link language for target "EmptyEpsilon". -- Generating done
Just for kicks, I created a brand new directory with completely fresh source and tried again - same results.
I gotta be doing _something_ wrong, just don't know what.
Yup - it needed the trailing slash but seemed to work ok w/o the current directory period (wonder why?). Compiling as I write this. I'll let you know what happens.
I always put the trailing period if I'm building in the same directory. Not 100% sure it's needed, but it works. I'm building for Windows 32bit, Linux 32 & 64 bit. I have subdirectories for each build so I need two trailing periods at the end to refer to the cmake files in the parent of each system.
Linker runs into problems: Lots of undefined references - the first couple are:
CMakeFiles/EmptyEpsilon.dir/src/particleEffect.cpp.o: In function `ParticleEngine::render()': particleEffect.cpp:(.text+0x8e): undefined reference to `sf::Shader::setParameter(std::string const&, sf::Texture const&)' CMakeFiles/EmptyEpsilon.dir/src/modelInfo.cpp.o: In function `ModelInfo::renderOverlay(sf::Texture*, float)': modelInfo.cpp:(.text+0xa48): undefined reference to `sf::Shader::setParameter(std::string const&, sf::Texture const&)' CMakeFiles/EmptyEpsilon.dir/src/modelInfo.cpp.o: In function `ModelInfo::renderShield(float)': modelInfo.cpp:(.text+0xb57): undefined reference to `sf::Shader::setParameter(std::string const&, sf::Texture const&)'
I did note during the cmake session that:
runtime library [libsfml-system.so.2.3] in /usr/lib may be hidden by files in: /usr/local/lib runtime library [libsfml-window.so.2.3] in /usr/lib may be hidden by files in: /usr/local/lib runtime library [libsfml-graphics.so.2.3] in /usr/lib may be hidden by files in: /usr/local/lib runtime library [libsfml-network.so.2.3] in /usr/lib may be hidden by files in: /usr/local/lib runtime library [libsfml-audio.so.2.3] in /usr/lib may be hidden by files in: /usr/local/lib
I figured that since all versions match in both directories (ie. 2.3.1) it should still work. I'm just wondering where the linker is actually looking to resolve these references.
Did you happen to run the CMake line again after removing and reinstalling SFML-2.3.1? Not sure if that would fix it, but it shouldn't hurt.
Edit: I usually delete CMakeFiles CMakeCache.txt & *.cmake to clean up old CMake data. Don't delete CMakeLIsts.txt as that's what CMake reads to build the Makefile
I'm using SFML-2.3.2 from Git - https://github.com/SFML/SFML (2.3.x branch) and naming the directory SFML-2.3. Then I'm specifying that directory using CMake. Not sure if it matters or not.
On a bare debian stable install the following should work, as not specifing where SeriousProton is, it will look at the same level as the EmptyEpsilon directory.
I just finished updating my Vagrantfile for building for Debian 32bit and Windows 32bit. Eventually the install and build script will be separated out to make them reuseable. Also will need a little clean up and some error checking, but it's working for me.
Comments
I'm trying to build EE on Linux - using EE source downloaded a week ago (Same for Serious Proton) and SFML 2.3.1. Building Linux Release using Code Blocks. Compiles beautifully until:
Compiling: src/modelData.cpp
In file included from /home/gene/epsilon/EmptyEpsilon-master/src/modelData.cpp:1:0:
/home/gene/epsilon/SFML-2.3.1/include/SFML/OpenGL.hpp:54:27: fatal error: GL/gl.h: No such file or directory
compilation terminated.
Can't find this file anywhere. Think I've seen this before but I can't remember the solution. Any ideas??
Thanks,
Gene
Installing on Debian/Ubuntu: apt-get install mesa-common-dev
Not sure about other Linux distros.
Yup - that did it - thanks
Now - has anyone managed to build EE on FreeBSD ?
There seems to be problems with the format of the SFML libraries. Apparently one cannot simply download the Linux version - the code compiled on Unix doesn't match up.
Any ideas how to fix this one (I'm not a cmake person)
Thanks
PS - working on BSD
cmake -DSERIOUS_PROTON_DIR=../SeriousProton -DSFML_ROOT=../SFML-2.3 .
I run this from the EmptyEpsilon directory. SeriousProton and SFML-2.3 are in the same parent directory as EmptyEpsilon.
Directory Structure looks like:
drwxr-xr-x 12 user wheel 31 Dec 2 12:21 EmptyEpsilon/
drwxr-xr-x 11 user wheel 22 Dec 2 10:39 SFML-2.3.1/
drwxr-xr-x 4 user wheel 7 Nov 23 08:15 SeriousProton/
I used the following:
cmake -DSERIOUS_PROTON_DIR=../SeriousProton -DSFML_ROOT=../SFML-2.3.1
Result was:
CMake Error at CMakeLists.txt:49 (add_executable):
Cannot find source file:
../SeriousProtonsrc/soundManager.cpp
Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp
.hxx .in .txx
CMake Error: CMake can not determine linker language for target: EmptyEpsilon
CMake Error: Cannot determine link language for target "EmptyEpsilon".
-- Generating done
Just for kicks, I created a brand new directory with completely fresh source and tried again - same results.
I gotta be doing _something_ wrong, just don't know what.
Gene
cmake -DSERIOUS_PROTON_DIR=../SeriousProton/ -DSFML_ROOT=../SFML-2.3.1 .
(Don't forget the ending period.)
I always put the trailing period if I'm building in the same directory. Not 100% sure it's needed, but it works.
I'm building for Windows 32bit, Linux 32 & 64 bit. I have subdirectories for each build so I need two trailing periods at the end to refer to the cmake files in the parent of each system.
Linker runs into problems: Lots of undefined references - the first couple are:
CMakeFiles/EmptyEpsilon.dir/src/particleEffect.cpp.o: In function `ParticleEngine::render()':
particleEffect.cpp:(.text+0x8e): undefined reference to `sf::Shader::setParameter(std::string const&, sf::Texture const&)'
CMakeFiles/EmptyEpsilon.dir/src/modelInfo.cpp.o: In function `ModelInfo::renderOverlay(sf::Texture*, float)':
modelInfo.cpp:(.text+0xa48): undefined reference to `sf::Shader::setParameter(std::string const&, sf::Texture const&)'
CMakeFiles/EmptyEpsilon.dir/src/modelInfo.cpp.o: In function `ModelInfo::renderShield(float)':
modelInfo.cpp:(.text+0xb57): undefined reference to `sf::Shader::setParameter(std::string const&, sf::Texture const&)'
I did note during the cmake session that:
runtime library [libsfml-system.so.2.3] in /usr/lib may be hidden by files in:
/usr/local/lib
runtime library [libsfml-window.so.2.3] in /usr/lib may be hidden by files in:
/usr/local/lib
runtime library [libsfml-graphics.so.2.3] in /usr/lib may be hidden by files in:
/usr/local/lib
runtime library [libsfml-network.so.2.3] in /usr/lib may be hidden by files in:
/usr/local/lib
runtime library [libsfml-audio.so.2.3] in /usr/lib may be hidden by files in:
/usr/local/lib
I figured that since all versions match in both directories (ie. 2.3.1) it should still work. I'm just wondering where the linker is actually looking to resolve these references.
I believe this has something to do with SeriousProton, due to the sf::Shader::setParameter.
Mostly a guess & I'm not sure if this is it or not, but, do you perhaps have a different version of SFML installed already?
Yes - let me dump the older versions, reinstall 2.3.1, and see what happens.
Got rid of the conflict reported by cmake (/usr/lib vs. /usr/local/lib) so cmake step was clean. But linker errors remain.
I'm starting the build using 'make'. Should I be using cmake? cmake created 'Makefile' so I'm just assuming that 'make' should be used.
Of course this is after running the cmake commands we discussed eariler.
Edit:
I usually delete CMakeFiles CMakeCache.txt & *.cmake to clean up old CMake data.
Don't delete CMakeLIsts.txt as that's what CMake reads to build the Makefile
I'm using SFML-2.3.2 from Git - https://github.com/SFML/SFML (2.3.x branch) and naming the directory SFML-2.3. Then I'm specifying that directory using CMake. Not sure if it matters or not.
https://github.com/kwadroke/linux-scripts/blob/master/vagrant/bridgesims/EmptyEpsilon/Vagrantfile.debian-x86
This will put a zip file with all the needed files (at least for Windows) in the same directory that your ran "vagrant up".