New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New Install on Mac OSX fails to launch: #2720

Open
ejohnso9 opened this Issue Jun 18, 2017 · 8 comments

Comments

Projects
None yet
5 participants
@ejohnso9

ejohnso9 commented Jun 18, 2017

Found your game mentioned here: https://www.slant.co/topics/1933/~open-source-games

I am a software developer, but not in games industry. Python is sort of my favorite language - used it professionally a little bit, but not as much as I would like. I was sort of looking for a project I might get involved with.

At any rate, I am off to a very sad start. After installing application, it fails to launch. System error console has this to say:

6/18/17 12:10:02.673 AM Unknown Horizons[5207]: Failed to use FIFE from <module 'fife' from '/Applications/Unknown Horizons.app/Contents/Resources/lib/python2.7/fife/__init__.py'>
6/18/17 12:10:02.673 AM Unknown Horizons[5207]: dlopen(/Applications/Unknown Horizons.app/Contents/Resources/lib/python2.7/fife/_fife.so, 2): Symbol not found: _fchmodat
6/18/17 12:10:02.673 AM Unknown Horizons[5207]:   Referenced from: /Applications/Unknown Horizons.app/Contents/MacOS/../Frameworks/libboost_filesystem-mt.dylib
6/18/17 12:10:02.674 AM Unknown Horizons[5207]:   Expected in: /usr/lib/libSystem.B.dylib
6/18/17 12:10:02.674 AM Unknown Horizons[5207]:  in /Applications/Unknown Horizons.app/Contents/MacOS/../Frameworks/libboost_filesystem-mt.dylib
6/18/17 12:10:02.730 AM Unknown Horizons[5207]: Failed to find and/or load FIFE.
6/18/17 12:10:02.794 AM Unknown Horizons[5207]: Traceback (most recent call last):
6/18/17 12:10:02.795 AM Unknown Horizons[5207]:   File "/Applications/Unknown Horizons.app/Contents/Resources/__boot__.py", line 351, in <module>
6/18/17 12:10:02.795 AM Unknown Horizons[5207]:     _run()
6/18/17 12:10:02.795 AM Unknown Horizons[5207]:   File "/Applications/Unknown Horizons.app/Contents/Resources/__boot__.py", line 336, in _run
6/18/17 12:10:02.795 AM Unknown Horizons[5207]:     exec(compile(source, path, 'exec'), globals(), globals())
6/18/17 12:10:02.795 AM Unknown Horizons[5207]:   File "/Applications/Unknown Horizons.app/Contents/Resources/run_uh.py", line 380, in <module>
6/18/17 12:10:02.795 AM Unknown Horizons[5207]:     main()
6/18/17 12:10:02.795 AM Unknown Horizons[5207]:   File "/Applications/Unknown Horizons.app/Contents/Resources/run_uh.py", line 172, in main
6/18/17 12:10:02.796 AM Unknown Horizons[5207]:     init_environment(True)
6/18/17 12:10:02.796 AM Unknown Horizons[5207]:   File "/Applications/Unknown Horizons.app/Contents/Resources/run_uh.py", line 364, in init_environment
6/18/17 12:10:02.796 AM Unknown Horizons[5207]:     setup_fife()
6/18/17 12:10:02.796 AM Unknown Horizons[5207]:   File "/Applications/Unknown Horizons.app/Contents/Resources/run_uh.py", line 344, in setup_fife
6/18/17 12:10:02.796 AM Unknown Horizons[5207]:     exit_with_error('Failed to find and/or load FIFE', 'Failed to find and/or load FIFE.')
6/18/17 12:10:02.796 AM Unknown Horizons[5207]:   File "/Applications/Unknown Horizons.app/Contents/Resources/run_uh.py", line 65, in exit_with_error
6/18/17 12:10:02.796 AM Unknown Horizons[5207]:     exit(1)
6/18/17 12:10:02.797 AM Unknown Horizons[5207]: NameError: global name 'exit' is not defined
6/18/17 12:10:02.987 AM Unknown Horizons[5207]: Unknown Horizons Error
6/18/17 12:10:02.988 AM Unknown Horizons[5207]: 2017-06-18 00:10:02.986 Unknown Horizons[5207:707] Unknown Horizons Error
6/18/17 12:10:11.932 AM com.apple.launchd.peruser.501[339]: ([0x0-0x84084].org.unknown-horizons[5207]) Exited with code: 255
6/18/17 12:10:12.153 AM Console[5221]: setPresentationOptions called with NSApplicationPresentationFullScreen when there is no visible fullscreen window; this call will be ignored.

My machine is a Mac Minin running OSX version 10.9.5

$ pwd
/usr/lib
$ ls -l libSy*
-rwxr-xr-x  1 root  wheel  59088 Jul 20  2016 libSystem.B.dylib
-rwxr-xr-x  1 root  wheel  67200 Mar 10  2015 libSystem.B_debug.dylib
lrwxr-xr-x  1 root  wheel     17 Jul 19  2014 libSystem.dylib -> libSystem.B.dylib
lrwxr-xr-x  1 root  wheel     23 Mar 10  2015 libSystem_debug.dylib -> libSystem.B_debug.dylib
$ cksum libSy*
345095999 59088 libSystem.B.dylib
2993899395 67200 libSystem.B_debug.dylib
345095999 59088 libSystem.dylib
2993899395 67200 libSystem_debug.dylib

Some of this is probably a bit beyond my experience, but if I am right in guessing that the problem starts with the expectation that my system /usr/lib/libSystem.B.dylib is supposed to be defining code for: _fchmodat
then this command would seem to verify that that symbol is not defined there (command gives no output):

$ nm libSystem.B.dylib | grep fchmo

Anyway... I'd love to see the game. I may try it on Windows 10 laptop or Raspberry Pi a bit later.

@squiddy

This comment has been minimized.

Show comment
Hide comment
@squiddy

squiddy Jun 18, 2017

Member

Hi there. :)

I'm sorry you had such a terrible experience. Unfortunately, we haven't had a macOS developer in a while. As such, we probably can not give you the solution right away, but perhaps we can figure this out together.

Judging by the traceback, you've installed the package from our website, which means it's release 2014.1. Some googling seems to suggest this is related to the Boost library used by FIFE, our engine:

http://ms-cheminfo.com/?q=node/90

https://svn.boost.org/trac10/ticket/10591#comment:4

Apple does implement fchmodat from OS X 10.10 and iOS 8.0.

This means that fchmodat will only be available when targeting OS X 10.10+ or iOS 8.0+, but the AT_* constants are always defined when building on 10.10, so they cannot be used for detection whether fchmodat is available.

This is out of my league really, but I'm guessing that FIFE for Mac was build on a newer version of macOS than 10.9, thereby introducing this error.


We've recently switched to Python 3.5 instead of 2.7 and released 2017.1 and 2017.2. We're still looking for someone that can help with a new release for Mac. I think at the moment, none of the few active developers has any knowledge about how one is supposed to build a package. Any help would be really appreciated. :)

Member

squiddy commented Jun 18, 2017

Hi there. :)

I'm sorry you had such a terrible experience. Unfortunately, we haven't had a macOS developer in a while. As such, we probably can not give you the solution right away, but perhaps we can figure this out together.

Judging by the traceback, you've installed the package from our website, which means it's release 2014.1. Some googling seems to suggest this is related to the Boost library used by FIFE, our engine:

http://ms-cheminfo.com/?q=node/90

https://svn.boost.org/trac10/ticket/10591#comment:4

Apple does implement fchmodat from OS X 10.10 and iOS 8.0.

This means that fchmodat will only be available when targeting OS X 10.10+ or iOS 8.0+, but the AT_* constants are always defined when building on 10.10, so they cannot be used for detection whether fchmodat is available.

This is out of my league really, but I'm guessing that FIFE for Mac was build on a newer version of macOS than 10.9, thereby introducing this error.


We've recently switched to Python 3.5 instead of 2.7 and released 2017.1 and 2017.2. We're still looking for someone that can help with a new release for Mac. I think at the moment, none of the few active developers has any knowledge about how one is supposed to build a package. Any help would be really appreciated. :)

@ejohnso9

This comment has been minimized.

Show comment
Hide comment
@ejohnso9

ejohnso9 Jun 19, 2017

Hi, Reiner.
Thanks for your reply. Getting any sort of response at all is very
encouraging.

This is sort of long, but I decided to write it all in the hopes it will be
useful.

So, first of all, you are correct, I installed Unknown Horizons by just
downloading the .dmg file from here:

https://github.com/unknown-horizons/unknown-horizons/releases/download/2014.1/Unknown-Horizons-2014.1.dmg

I notice now that that is version 2014.1, so I guess that is quite old, anyway.

I also have not yet tried to get the game running on my Laptop (Windows 10) or
on my Raspberry PI (which might be a platform you guys would want to investigate
as it has a very DIY/indie sort of culture and might be fertile grounds for
gaining new developers for UH and/or FIFE. It also tends to have a rather Pythonic fan base.)

So, there's sort of two facets to discuss here. One is the specific technical
issue regarding _fchmodat, and then the broader topic of the UH project and me
trying to find some way to be a useful part of that.

I don't know if this project has any direct relation to Patrician II (Ascaron
Entertainment), but I owned and played that game quite a few years ago and I
thought it was great. Just in looking at the home page for Unknown Horizons, it
would seem like there is a lot of similarity. (As an older adult, I am sort of
worn out on shooting games and endless mob slaying stuff. The simulated
violence doesn't bother me per-se, but it just seems not that interesting to me
at this stage in life.)

So, I love to play games and want to play your game, but there are secondary
goals for me:

* To spend some of my free time doing something productive that
    makes me a better, more confident programmer.
    
* To learn more about git and how to use it reliably.

* To learn more about game design, to spend time digging through game code
    and learn from that code.

* To have the experience of having interacted with other developers around
    the world on a real project.

* To give something back to the open source community. (I have benefitted
    from various free and open source software along the way, like vim,
    played GNU Backgammon, installed and used cygwin, etc.  I even got to
   see Richard Stallman talk once when he came to my university to talk about
   "free" software. My life in the open source communuty so far has been as a consumer 
    rather than as a contributor.)

I have some ideas of my own about producing a programming-related game, but
right now, rather than talking about that, I think it would be better for me to
improve my skills related to game development and try to figure out how I can
do some useful things for your project.

I don't really consider myself a Mac developer. Rather, I am more of a web
developer that happens to own and use a Mac at home for my personal
entertainment, email, etc.

Most of my professional time is spent digging through Java, JavaScript, or
ColdFusion code, running SQL queries against tables, inspecting stored
procedures, etc. trying to track down application-specific problems. I rarely
get very close to the OS, and rarely compile anything in C or C++. I did do
some professional programming in C about 20 years ago, and took an academic
course in C++, so I sort of know enough "to be dangerous" in that area, but
it's not my forte.

I'm not in a huge hurry to have anything in particular resolved.

So, this morning (I am in Mountain timezone in America, GMT +7/+8), I figured I
would just try to go get FIFE installed directly and work with that for
starters. I seem to be having a bit of a rough time with that as well.

Let's see if I can provide some useful feedback on that front...

Looks like you've just got a Documentation placeholder for how to install FIFE:
http://docs.fifengine.net/user-manual/en/#_getting_started

Ok... some things can be inferred. I basically:

1) did a git clone, got the files locally

2) looked at README.md - it doesn't really say anything about building
    per se, but I see setup.py - that's more or less standard. (Maybe there
    will be places I can help with documentation as well.)

3) executed 
    $ python setup.py --help
    $ python setup.py build

4) started trying to execute tests:
    $ python run_tests.py

    This gives a numbered menu of tests. Item number 9, 26, and 30 are all
    labelled "all", then there's #31: "Run all tests". So, that doesn't
    make much sense. At any rate, after picking test 0, here's the output:

    ===== Running test_dat1 =====
    sh: build/tests/debug/test_dat1: No such file or directory

    Well, sure enough, there no such dir build/tests/

5) I figured: OK, I'm missing some step. Let's get this installed, rather
    than just built:

    $ sudo python setup.py install

    That generates a lot of output and looks like it went OK but,
    unfortunately, doesn't change the output to run_tests.py.

    So, the content of README.md is actually telling you to do something
    different for tests (not run run_test.py):

    ## 3) Tests

    The test tool can be found within the `<FIFE>/tests/fife_test` directory.
    You can launch it by running `run.py`. Open the console with `F10`.
    To run a test enter `run` and the test name like `PathfinderTest`.

    OK, good news: there is a:
        <FIFE>/tests/fife_test/run.py

    $ python run.py

    Bad news: here's the output:

    Traceback (most recent call last):
      File "run.py", line 33, in <module>
          from fife import fife
          ImportError: cannot import name fife

So, this is also kind of frustrating... Luckily, as I said, I'm not in a big
hurry. Maybe this is another area where I can contribute. I didn't mention
that software testing is an area I have an interest in (and a little
professional experience, but not very much).

The test would seem to imply my fife is hosed, but I seem to have some sort of
fife module. If I just invoke Python (2.7), and import fife, it returns
silently. Here's the help:

Help on package fife:

NAME
fife - # -- coding: utf-8 --

FILE
/Library/Python/2.7/site-packages/fife/init.py

PACKAGE CONTENTS
extensions (package)

DATA
all = ['fife']

(END)

The standard way to check the version would be:

fife.version
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'module' object has no attribute 'version'

:( So, there's another place for improvement. Maybe fife module is fine here?
It's not clear. Presumably it would be the latest stuff I guess since I just
checked it out from the git repo, right? There are some pitfalls in
documentation and programming. I would like to see getting FIFE installed, and
runnning all the tests and seeing all the passing output be a real no-brainer.
Then a developer can move swiftly on to running demos and so on.

I haven't written my own setup.py files before, but I've dug through a few,
when things haven't gone right. I have seen some rather surprising/sophisticated
things happen. Take for example, an install that wants to know whether a
system is big endian or little endian. Rather than try to map out all the known
systems and lacking any sort of standard API that just tells you, I have seen an
install script just locate cc or gcc, verify it can be run, dump some C source
into a temp file, invoke the compiler on the temp file producing an executable
a.out, then build a pipe to a.out and read the output to infer byte-endianess.

(I believe CPython itself also has a C-compiler wrapped up in itself and a
module to use it? Another area I don't know a lot about.)

With an install language like Python, an incredible amount of power is
available. It may take a fair amount of programming, but you can do things like
verify whether a system has a particular shared library and actually look at
'nm' output and determine "Is _fchmodat actually defined there or isn't it?" Do
we know other places it might be defined? If we know we have to have _fchmodat,
have we found some place that provides it? If not, can we provide it
ourselves? If not, we KNOW up front, this install has got issues. Can we
direct the user to install something newer that will resolve it? (I'm not
trying to beat anybody up for not doing all that, just pointing out that all of
that sort of stuff is possible.)

This is getting quite long. Let me try to hit some of the high level ideas I've
got right now, and wrap this up.

One thought is that the install of your game could all be quite dynamic. You
could simply publish a setup.py, and then say:

Do this:

$ python setup.py

And from there, with enough scripting, the rest of the pieces can fall in
place. You can fetch whatever the most-recently approved boost source is, you
can compile it in place, then build FIFE, run it's tests and make sure that's
all happy, pull in UH source, get those modules in place, make sure that's all
happy etc. (Not having gone through all that myself, it's an idea at this point
and I am not claiming it is necessarily practical, merely possible.)

Since you are currently distributing a .dmg for Mac OSX that is both broken for
OS 10.9 and earlier, and is 2014 UH code anyway, another approach is to get
your distribution updated for 2017. Perhaps you will need two different OSX
distributions, one for 10.9 and earlier, one for 10.10 and after. This is not
an easy task of course if you don't have the manpower as well as various
machines to test on.

I am not clear on the relationship between Boost and FIFE, exactly, nor how you
would go about building a .dmg for app distribution. You did it previously. If
you can provide some hints about how it was done in the past, maybe I can help
you to get it done again.

Right now, the distribution I have for UH is the .dmg you published. It seems
like there should be an alternate way to get UH source directly such that that
could be put together with either FIFE (as a whole) or a local build of Boost
which is then put together with FIFE.

There is a new version of Boost as of April 19th of this year. I'm not quite
clear on what the Boost code is trying to do regarding with the fchmodat flag
(AT_SYMLINK_NOFOLLOW). Either they are on a system that is defining that
symbol (OSX 10.10+), or they are not. If not, then Boost has to have some sort
of switch to accomplish what it's got to do without fchmodat, or provide it's
own implementation. I don't really want to know all of those details, but I
can try to make my own build of Boost later this week.

If you can give me some clues about how that fits together with FIFE and the
way the current .dmg you are distributing is put together, maybe I can find
some way to give you a .dmg to distribute with new Boost code and your 2017
UH code base? I think I need some more info about how FIFE is built, and how
that relates to running UH.

Maybe more documentation about what these major pieces are, how they are
generated, and how they come together to produce a running Unknown Horizons is a
beneficial thing the UH project is missing? (Or maybe scripts that actually
fetch the disparate pieces and build them from source locally and actually fit
them together into a running UH.)

So, yes, let's work together on this. Let's keep the conversation going and see
if we can help each other.

I will dig through the FIFE setup.py some, but if there's some way to quickly
clarify the documentation and get tests to execute correctly, that might be a
great place to prevent another potential developer from going through this.

Thanks,
-ej (AKA Erik Johnnson, ejohnso9)

ejohnso9 commented Jun 19, 2017

Hi, Reiner.
Thanks for your reply. Getting any sort of response at all is very
encouraging.

This is sort of long, but I decided to write it all in the hopes it will be
useful.

So, first of all, you are correct, I installed Unknown Horizons by just
downloading the .dmg file from here:

https://github.com/unknown-horizons/unknown-horizons/releases/download/2014.1/Unknown-Horizons-2014.1.dmg

I notice now that that is version 2014.1, so I guess that is quite old, anyway.

I also have not yet tried to get the game running on my Laptop (Windows 10) or
on my Raspberry PI (which might be a platform you guys would want to investigate
as it has a very DIY/indie sort of culture and might be fertile grounds for
gaining new developers for UH and/or FIFE. It also tends to have a rather Pythonic fan base.)

So, there's sort of two facets to discuss here. One is the specific technical
issue regarding _fchmodat, and then the broader topic of the UH project and me
trying to find some way to be a useful part of that.

I don't know if this project has any direct relation to Patrician II (Ascaron
Entertainment), but I owned and played that game quite a few years ago and I
thought it was great. Just in looking at the home page for Unknown Horizons, it
would seem like there is a lot of similarity. (As an older adult, I am sort of
worn out on shooting games and endless mob slaying stuff. The simulated
violence doesn't bother me per-se, but it just seems not that interesting to me
at this stage in life.)

So, I love to play games and want to play your game, but there are secondary
goals for me:

* To spend some of my free time doing something productive that
    makes me a better, more confident programmer.
    
* To learn more about git and how to use it reliably.

* To learn more about game design, to spend time digging through game code
    and learn from that code.

* To have the experience of having interacted with other developers around
    the world on a real project.

* To give something back to the open source community. (I have benefitted
    from various free and open source software along the way, like vim,
    played GNU Backgammon, installed and used cygwin, etc.  I even got to
   see Richard Stallman talk once when he came to my university to talk about
   "free" software. My life in the open source communuty so far has been as a consumer 
    rather than as a contributor.)

I have some ideas of my own about producing a programming-related game, but
right now, rather than talking about that, I think it would be better for me to
improve my skills related to game development and try to figure out how I can
do some useful things for your project.

I don't really consider myself a Mac developer. Rather, I am more of a web
developer that happens to own and use a Mac at home for my personal
entertainment, email, etc.

Most of my professional time is spent digging through Java, JavaScript, or
ColdFusion code, running SQL queries against tables, inspecting stored
procedures, etc. trying to track down application-specific problems. I rarely
get very close to the OS, and rarely compile anything in C or C++. I did do
some professional programming in C about 20 years ago, and took an academic
course in C++, so I sort of know enough "to be dangerous" in that area, but
it's not my forte.

I'm not in a huge hurry to have anything in particular resolved.

So, this morning (I am in Mountain timezone in America, GMT +7/+8), I figured I
would just try to go get FIFE installed directly and work with that for
starters. I seem to be having a bit of a rough time with that as well.

Let's see if I can provide some useful feedback on that front...

Looks like you've just got a Documentation placeholder for how to install FIFE:
http://docs.fifengine.net/user-manual/en/#_getting_started

Ok... some things can be inferred. I basically:

1) did a git clone, got the files locally

2) looked at README.md - it doesn't really say anything about building
    per se, but I see setup.py - that's more or less standard. (Maybe there
    will be places I can help with documentation as well.)

3) executed 
    $ python setup.py --help
    $ python setup.py build

4) started trying to execute tests:
    $ python run_tests.py

    This gives a numbered menu of tests. Item number 9, 26, and 30 are all
    labelled "all", then there's #31: "Run all tests". So, that doesn't
    make much sense. At any rate, after picking test 0, here's the output:

    ===== Running test_dat1 =====
    sh: build/tests/debug/test_dat1: No such file or directory

    Well, sure enough, there no such dir build/tests/

5) I figured: OK, I'm missing some step. Let's get this installed, rather
    than just built:

    $ sudo python setup.py install

    That generates a lot of output and looks like it went OK but,
    unfortunately, doesn't change the output to run_tests.py.

    So, the content of README.md is actually telling you to do something
    different for tests (not run run_test.py):

    ## 3) Tests

    The test tool can be found within the `<FIFE>/tests/fife_test` directory.
    You can launch it by running `run.py`. Open the console with `F10`.
    To run a test enter `run` and the test name like `PathfinderTest`.

    OK, good news: there is a:
        <FIFE>/tests/fife_test/run.py

    $ python run.py

    Bad news: here's the output:

    Traceback (most recent call last):
      File "run.py", line 33, in <module>
          from fife import fife
          ImportError: cannot import name fife

So, this is also kind of frustrating... Luckily, as I said, I'm not in a big
hurry. Maybe this is another area where I can contribute. I didn't mention
that software testing is an area I have an interest in (and a little
professional experience, but not very much).

The test would seem to imply my fife is hosed, but I seem to have some sort of
fife module. If I just invoke Python (2.7), and import fife, it returns
silently. Here's the help:

Help on package fife:

NAME
fife - # -- coding: utf-8 --

FILE
/Library/Python/2.7/site-packages/fife/init.py

PACKAGE CONTENTS
extensions (package)

DATA
all = ['fife']

(END)

The standard way to check the version would be:

fife.version
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'module' object has no attribute 'version'

:( So, there's another place for improvement. Maybe fife module is fine here?
It's not clear. Presumably it would be the latest stuff I guess since I just
checked it out from the git repo, right? There are some pitfalls in
documentation and programming. I would like to see getting FIFE installed, and
runnning all the tests and seeing all the passing output be a real no-brainer.
Then a developer can move swiftly on to running demos and so on.

I haven't written my own setup.py files before, but I've dug through a few,
when things haven't gone right. I have seen some rather surprising/sophisticated
things happen. Take for example, an install that wants to know whether a
system is big endian or little endian. Rather than try to map out all the known
systems and lacking any sort of standard API that just tells you, I have seen an
install script just locate cc or gcc, verify it can be run, dump some C source
into a temp file, invoke the compiler on the temp file producing an executable
a.out, then build a pipe to a.out and read the output to infer byte-endianess.

(I believe CPython itself also has a C-compiler wrapped up in itself and a
module to use it? Another area I don't know a lot about.)

With an install language like Python, an incredible amount of power is
available. It may take a fair amount of programming, but you can do things like
verify whether a system has a particular shared library and actually look at
'nm' output and determine "Is _fchmodat actually defined there or isn't it?" Do
we know other places it might be defined? If we know we have to have _fchmodat,
have we found some place that provides it? If not, can we provide it
ourselves? If not, we KNOW up front, this install has got issues. Can we
direct the user to install something newer that will resolve it? (I'm not
trying to beat anybody up for not doing all that, just pointing out that all of
that sort of stuff is possible.)

This is getting quite long. Let me try to hit some of the high level ideas I've
got right now, and wrap this up.

One thought is that the install of your game could all be quite dynamic. You
could simply publish a setup.py, and then say:

Do this:

$ python setup.py

And from there, with enough scripting, the rest of the pieces can fall in
place. You can fetch whatever the most-recently approved boost source is, you
can compile it in place, then build FIFE, run it's tests and make sure that's
all happy, pull in UH source, get those modules in place, make sure that's all
happy etc. (Not having gone through all that myself, it's an idea at this point
and I am not claiming it is necessarily practical, merely possible.)

Since you are currently distributing a .dmg for Mac OSX that is both broken for
OS 10.9 and earlier, and is 2014 UH code anyway, another approach is to get
your distribution updated for 2017. Perhaps you will need two different OSX
distributions, one for 10.9 and earlier, one for 10.10 and after. This is not
an easy task of course if you don't have the manpower as well as various
machines to test on.

I am not clear on the relationship between Boost and FIFE, exactly, nor how you
would go about building a .dmg for app distribution. You did it previously. If
you can provide some hints about how it was done in the past, maybe I can help
you to get it done again.

Right now, the distribution I have for UH is the .dmg you published. It seems
like there should be an alternate way to get UH source directly such that that
could be put together with either FIFE (as a whole) or a local build of Boost
which is then put together with FIFE.

There is a new version of Boost as of April 19th of this year. I'm not quite
clear on what the Boost code is trying to do regarding with the fchmodat flag
(AT_SYMLINK_NOFOLLOW). Either they are on a system that is defining that
symbol (OSX 10.10+), or they are not. If not, then Boost has to have some sort
of switch to accomplish what it's got to do without fchmodat, or provide it's
own implementation. I don't really want to know all of those details, but I
can try to make my own build of Boost later this week.

If you can give me some clues about how that fits together with FIFE and the
way the current .dmg you are distributing is put together, maybe I can find
some way to give you a .dmg to distribute with new Boost code and your 2017
UH code base? I think I need some more info about how FIFE is built, and how
that relates to running UH.

Maybe more documentation about what these major pieces are, how they are
generated, and how they come together to produce a running Unknown Horizons is a
beneficial thing the UH project is missing? (Or maybe scripts that actually
fetch the disparate pieces and build them from source locally and actually fit
them together into a running UH.)

So, yes, let's work together on this. Let's keep the conversation going and see
if we can help each other.

I will dig through the FIFE setup.py some, but if there's some way to quickly
clarify the documentation and get tests to execute correctly, that might be a
great place to prevent another potential developer from going through this.

Thanks,
-ej (AKA Erik Johnnson, ejohnso9)

@LinuxDonald

This comment has been minimized.

Show comment
Hide comment
@LinuxDonald

LinuxDonald Jun 19, 2017

Member

Uh needs python3 support. On Travis we use this command for it to build fifengine with python3 support:

cmake -DPYTHON_EXECUTABLE:PATH=/usr/local/bin/python3 -DPYTHON_INCLUDE_DIR=/Library/Frameworks/Python.framework/Versions/3.6/include/python3.6m -DPYTHON_LIBRARY=/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6 ../fifengine

But it still not works there. We dont know if the paths are correct.

Member

LinuxDonald commented Jun 19, 2017

Uh needs python3 support. On Travis we use this command for it to build fifengine with python3 support:

cmake -DPYTHON_EXECUTABLE:PATH=/usr/local/bin/python3 -DPYTHON_INCLUDE_DIR=/Library/Frameworks/Python.framework/Versions/3.6/include/python3.6m -DPYTHON_LIBRARY=/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6 ../fifengine

But it still not works there. We dont know if the paths are correct.

@ejohnso9

This comment has been minimized.

Show comment
Hide comment
@ejohnso9

ejohnso9 Jun 19, 2017

fifengine/setup.py already imports sys

A simple statement like this would make this Python 3 requirement both explicit and enforced:

if sys.version_info[0] != 3: print("This script requires Python version 3.x") sys.exit(1)

(how do you get Python formatted correctly here?)

https://stackoverflow.com/questions/6224736/how-to-write-python-code-that-is-able-to-properly-require-a-minimal-python-versi

After re-getting the FIFE library via git, and running:
$ python3 setup.py build $ python3 setup.py install

And then trying to run:
'$ python3 run_tests.py'

You get a syntax error because your test script is using Python 2 syntax.

If you run run_tests.py and just select 0, using Python 2, you still get this error:
'===== Running test_dat1 =====
The system cannot find the path specified.'

.../fifengine/tests/fife_test/run.py is also in Python2 syntax.

Running it still errors.

If you just run Python3 (3.3.5), and try this:

'>>> from fife import fife'

you still get this:

'Traceback (most recent call last):
File "", line 1, in
ImportError: cannot import name fife
'

So... umm..... gosh.... all of this that I am saying in this post has been redone on a Windows 7 Enterprise machine. I am having much the same problems, and this has nothing to do with whether Apple defines _fchmodat

These issues of just downloading FIFE via git, building it, installing it, and then verifying that you can't:

'>>> from fife import fife'

Should be easily verifiable by pretty much anyone.

Not sure I can do much to help you at this point other than point out these problems.

If you download new fifengine from git, build and install it with Python 3, can you run any of the tests?

ejohnso9 commented Jun 19, 2017

fifengine/setup.py already imports sys

A simple statement like this would make this Python 3 requirement both explicit and enforced:

if sys.version_info[0] != 3: print("This script requires Python version 3.x") sys.exit(1)

(how do you get Python formatted correctly here?)

https://stackoverflow.com/questions/6224736/how-to-write-python-code-that-is-able-to-properly-require-a-minimal-python-versi

After re-getting the FIFE library via git, and running:
$ python3 setup.py build $ python3 setup.py install

And then trying to run:
'$ python3 run_tests.py'

You get a syntax error because your test script is using Python 2 syntax.

If you run run_tests.py and just select 0, using Python 2, you still get this error:
'===== Running test_dat1 =====
The system cannot find the path specified.'

.../fifengine/tests/fife_test/run.py is also in Python2 syntax.

Running it still errors.

If you just run Python3 (3.3.5), and try this:

'>>> from fife import fife'

you still get this:

'Traceback (most recent call last):
File "", line 1, in
ImportError: cannot import name fife
'

So... umm..... gosh.... all of this that I am saying in this post has been redone on a Windows 7 Enterprise machine. I am having much the same problems, and this has nothing to do with whether Apple defines _fchmodat

These issues of just downloading FIFE via git, building it, installing it, and then verifying that you can't:

'>>> from fife import fife'

Should be easily verifiable by pretty much anyone.

Not sure I can do much to help you at this point other than point out these problems.

If you download new fifengine from git, build and install it with Python 3, can you run any of the tests?

@MasterofJOKers

This comment has been minimized.

Show comment
Hide comment
@MasterofJOKers

MasterofJOKers Jun 19, 2017

Contributor

Fife supports both python3 and python2. They cannot enforce python3. UH needs python3 module for fife, though.

Contributor

MasterofJOKers commented Jun 19, 2017

Fife supports both python3 and python2. They cannot enforce python3. UH needs python3 module for fife, though.

@MasterofJOKers

This comment has been minimized.

Show comment
Hide comment
@MasterofJOKers

MasterofJOKers Jun 19, 2017

Contributor

Additionally, fife's python support is only an added feature (via swig). Fife itself is written in C++ and needs to be compiled using cmake. I don't think python setup.py build is enough here. You need to run cmake as shown in fife's docs.

Contributor

MasterofJOKers commented Jun 19, 2017

Additionally, fife's python support is only an added feature (via swig). Fife itself is written in C++ and needs to be compiled using cmake. I don't think python setup.py build is enough here. You need to run cmake as shown in fife's docs.

@ejohnso9

This comment has been minimized.

Show comment
Hide comment
@ejohnso9

ejohnso9 Jun 20, 2017

Thanks for your reply, MasterofJOKers. I expect you are completely right. I am just trying to get some sort of running installation so I can look at the game, and then start to look at buglists and see if I can do anything useful, either for UH or for FIFE, preferably UH itself.

So, I guess when you install UH from the git repository and build that using the Python setup.py, the assumption is that fife is already installed, right? I wasn't sure if maybe the Python install of UH would just bring in some pre-compiled FIFE from somewhere. After getting through a successful build and install of UH using Python 3, it appears I have no FIFE, so I guess not. :(

As the FIFE documentation states: "Compiling Fifengine is a complicated and time consuming task." I was sort of hoping to avoid that. I did read through the compilation docs there a bit. Perhaps I will ultimately end up building FIFE myself, or maybe learn enough about how all the pieces hang together that I can get FIFE through standard Windows installer, then build UH from the git repository?

There doesn't seem to be a lot of UH documentation on how these pieces get generated and how you might mix and match to build a dev environment.

ejohnso9 commented Jun 20, 2017

Thanks for your reply, MasterofJOKers. I expect you are completely right. I am just trying to get some sort of running installation so I can look at the game, and then start to look at buglists and see if I can do anything useful, either for UH or for FIFE, preferably UH itself.

So, I guess when you install UH from the git repository and build that using the Python setup.py, the assumption is that fife is already installed, right? I wasn't sure if maybe the Python install of UH would just bring in some pre-compiled FIFE from somewhere. After getting through a successful build and install of UH using Python 3, it appears I have no FIFE, so I guess not. :(

As the FIFE documentation states: "Compiling Fifengine is a complicated and time consuming task." I was sort of hoping to avoid that. I did read through the compilation docs there a bit. Perhaps I will ultimately end up building FIFE myself, or maybe learn enough about how all the pieces hang together that I can get FIFE through standard Windows installer, then build UH from the git repository?

There doesn't seem to be a lot of UH documentation on how these pieces get generated and how you might mix and match to build a dev environment.

@AndyMender

This comment has been minimized.

Show comment
Hide comment
@AndyMender

AndyMender Jun 20, 2017

Member

Building the FIFE engine doesn't really take that much time. On a 3-year-old ultrabook the compilation takes approximately 15 min. To work on Unknown Horizons you need fifechan in addition, but that's even faster. Finally, UH itself doesn't require any building since it's pure Python :).

Member

AndyMender commented Jun 20, 2017

Building the FIFE engine doesn't really take that much time. On a 3-year-old ultrabook the compilation takes approximately 15 min. To work on Unknown Horizons you need fifechan in addition, but that's even faster. Finally, UH itself doesn't require any building since it's pure Python :).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment