Building from source

2»

Comments

  • 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. 


  • Successfully built!

    I now have a working version of the Mac game. I don't have anyone else to play with of course, but I'll have to see if I can fix that. 


    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?
  • edited November 2015
    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??

    Thanks,
    Gene

  • @Gene, You need the Mesa development files.

    Installing on Debian/Ubuntu: apt-get install mesa-common-dev
    Not sure about other Linux distros.
  • edited November 2015
    @kwadroke

    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.


  • I don't use the binaries from the SFML website. I compile SFML for both Linux & Windows. You will probably have to do the same for BSD.
  • Don't expect magic on BSD. OpenGL and BSD are most likely not that compatible.
  • Note, it's easier to use CMake to build EE. The codeblocks project is just legacy.
  • edited December 2015
    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)

    Thanks

    PS - working on BSD

  • Here's what I run to build on Linux.
    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.

  • OK -

    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

  • edited December 2015
    Try adding a "/" to the end SeriousProton directory name. I missed that from my script. (I retyped it since I have variables littered throughout.)

    cmake -DSERIOUS_PROTON_DIR=../SeriousProton/ -DSFML_ROOT=../SFML-2.3.1 .

    (Don't forget the ending period.)
  • 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.
  • edited December 2015
    Good to hear.

    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.
  • OK - compiled just fine but....

    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.


  • Honestly, this is the point I start to get lost myself. @Daid would be able to tell you about this better than I.

    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?
  • A slight possiblity is it could be something in the EmptyEpsilon/cmake/FindSFML.cmake file with its references to BSD.
  • > 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.



  • edited December 2015
    Dumped all other versions of SFML. Remaining are /usr/local/include/SFML (all 2.3.1 versions), and /usr/lib/libsfml*.so.*...

    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.

  • edited December 2015
    Yes, you should be building using make to compile.
    Of course this is after running the cmake commands we discussed eariler.


  • edited December 2015
    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.

    unzip SFML-2.3.2-sources.zip
    cd SFML-2.3.2
    cmake .
    make
    sudo make install
    sudo ldconfig
    cd ..
    cd EmptyEpsilon
    mkdir _build
    cd _build
    cmake ..
    make


    I also have this list of packages that needed to be installed for compiling SFML, but it's dated and as of SFML-2.3 isn't correct anymore:
    sudo apt-get install git build-essential libx11-dev cmake libxrandr-dev mesa-common-dev libglu1-mesa-dev libudev-dev libglew-dev libjpeg-dev libfreetype6-dev libopenal-dev libsndfile1-dev

    I think libsndfile1-dev was no longer needed, but libxcb1-dev or something like that is needed now.

    On my "base linux" system I also installed the following packages to get X working:
    sudo apt-get install xserver-xorg-core xserver-xorg-input-all xserver-xorg-video-all xinit alsa-base alsa-utils
    And start the game with "startx ./_build/EmptyEpsilon"

    My network boot install is a bit more complex.
  • 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.

    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".
Sign In or Register to comment.