Done. The buildbot is happy but our Mac build slave is too old for the case to
trigger. Alex, could you give it a try to see if you get a 64-bit build by
default now?

I'm optimistically setting this to resolved, if it doesn't work, we can reopen
the issue.

Looks good to me, please merge!

Thanks for the review. I handled your comments and I think we can merge this now.

Thanks, Florian! I left some comments on bitbucket.

Is this what you had in mind?
https://bitbucket.org/FlorianPommerening/downward-issues/pull-requests/52

Adding local variables to the build_configs script is a bit awkward because we
interpret them as build configurations by default. I put everything in a
function and removed it in the build script.

I suggest we put in a test if we're on Mojave or a more recent Mac release in
build_configs.py and change the default build and debug build to 64-bit in that
case. Apart from the build_configs.py, we should also update the documentation
of build.py and fast-downward.py that states what the defaults are, and the wiki.

Here is a Python script that determines some platform info:

======================================================================
from __future__ import print_function
import platform

print("platform", platform.platform())
print("release", platform.release())
print("system", platform.system())
print("system_alias", platform.system_alias(platform.system(),
platform.release(), platform.version()))
print("version", platform.version())
print("mac_ver", platform.mac_ver())
======================================================================

And here is the output that Alex got:
======================================================================

platform Darwin-18.0.0-x86_64-i386-64bit
release 18.0.0
system Darwin
system_alias ('Darwin', '18.0.0', 'Darwin Kernel Version 18.0.0: Wed Aug 22
20:13:40 PDT 2018; root:xnu-4903.201.2~1/RELEASE_X86_64')
version Darwin Kernel Version 18.0.0: Wed Aug 22 20:13:40 PDT 2018;
root:xnu-4903.201.2~1/RELEASE_X86_64
mac_ver ('10.14', ('', '', ''), 'x86_64')
======================================================================

After some googling, I suggest we test platform.system() == "Darwin" and then
determine the major release from platform.release() and test whether the first
component is >= 18. I'd use something like
int(platform.release().split(".")[0]), but guarding against an empty string (in
which case there is no 0-th component) and catching the ValueError that arises
when the first component is not numerical.

Anyone willing to take this one on?

For the record, here's some background info on Apple's discontinuation of 32-bit
software:

https://support.apple.com/en-us/HT208436

For some reason, the creator of the issue (Alexander) was not on the nosy list.
I have added him, so that he will get these messages.

Alexander, please check http://issues.fast-downward.org/issue854 for the
comments that your issue has received so far.

To elaborate on what Florian said: the reason why we currently force a 32-bit
build is because it has somewhat better performance. If this doesn't work any
more on the Mac, just using "./build.py release64" as Florian mentions is a
reasonable workaround. In the meantime, we have been working on making the
64-bit build as efficient as the 32-bit build, and we're already most of the way
there.

If "./build.py release64" doesn't work either, we have a different problem. In
that case, please let us know.

If mac OS doesn't support 32 bit builds anymore, there is not much we can do for
the default (32 bit) build. Does the 64 bit build still work? You can try it by
running

  ./build.py release64

We are currently moving away from a forced 32 bit or 64 bit build towards using
whatever is the native bitwidth but this will still take a while (issue213).

I'm moving the original message from the summary field to a regular message:

---

Building fast-downward on macOS Mojave no longer works. This is due to the fact
that the 10.14 SDK only includes the x86_64 parts. The i386 architecture is no
longer available. Error log from build.py:

CMake Error at
/usr/local/Cellar/cmake/3.12.3/share/cmake/Modules/CMakeTestCCompiler.cmake:52
(message):
  The C compiler

    "/usr/bin/gcc"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir:
/Users/arlyon/Programming/university/artificial-intelligence/fd/builds/release32/CMakeFiles/CMakeTmp

    Run Build Command:"/usr/local/bin/gmake" "cmTC_97323/fast"
    /usr/local/bin/gmake -f CMakeFiles/cmTC_97323.dir/build.make
CMakeFiles/cmTC_97323.dir/build
    gmake[1]: Entering directory
'/Users/arlyon/Programming/university/artificial-intelligence/fd/builds/release32/CMakeFiles/CMakeTmp'
    Building C object CMakeFiles/cmTC_97323.dir/testCCompiler.c.o
    /usr/bin/gcc   -m32  -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
  -o CMakeFiles/cmTC_97323.dir/testCCompiler.c.o   -c
/Users/arlyon/Programming/university/artificial-intelligence/fd/builds/release32/CMakeFiles/CMakeTmp/testCCompiler.c
    Linking C executable cmTC_97323
    /usr/local/Cellar/cmake/3.12.3/bin/cmake -E cmake_link_script
CMakeFiles/cmTC_97323.dir/link.txt --verbose=1
    /usr/bin/gcc  -m32  -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
-Wl,-search_paths_first -Wl,-headerpad_max_install_names  
CMakeFiles/cmTC_97323.dir/testCCompiler.c.o  -o cmTC_97323
    ld: warning: The i386 architecture is deprecated for macOS (remove from the
Xcode build setting: ARCHS)
    ld: warning: ignoring file
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/lib/libSystem.tbd,
missing required architecture i386 in file
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/lib/libSystem.tbd
    ld: dynamic main executables must link with libSystem.dylib for architecture
i386
    clang: error: linker command failed with exit code 1 (use -v to see invocation)
    gmake[1]: *** [CMakeFiles/cmTC_97323.dir/build.make:87: cmTC_97323] Error 1
    gmake[1]: Leaving directory
'/Users/arlyon/Programming/university/artificial-intelligence/fd/builds/release32/CMakeFiles/CMakeTmp'
    gmake: *** [Makefile:121: cmTC_97323/fast] Error 2




  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:44 (project)


-- Configuring incomplete, errors occurred!
See also
"/Users/arlyon/Programming/university/artificial-intelligence/fd/builds/release32/CMakeFiles/CMakeOutput.log".
See also
"/Users/arlyon/Programming/university/artificial-intelligence/fd/builds/release32/CMakeFiles/CMakeError.log".
Traceback (most recent call last):
  File "./build.py", line 153, in <module>
    main()
  File "./build.py", line 149, in main
    build(config_name, CONFIGS[config_name], make_parameters)
  File "./build.py", line 125, in build
    cwd=build_path)
  File "./build.py", line 102, in try_run
    subprocess.check_call(cmd, cwd=cwd)
  File "/Users/arlyon/.pyenv/versions/3.7.0/lib/python3.7/subprocess.py", line
328, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['cmake', '-G', 'Unix Makefiles',
'-DCMAKE_BUILD_TYPE=Release', '../../src']' returned non-zero exit status 1.

Here is a similar issue on another project:
https://github.com/ValveSoftware/Proton/issues/108