A downstream Linux fork of d2x-xl

All other topics around Descent and D2X-XL

Moderators: Frustikus, simX, Aus-RED-5

steel01
Posts: 89
Joined: Mon Jun 02, 2014 11:44 am

Re: A downstream Linux fork of d2x-xl

Postby steel01 » Tue Jul 22, 2014 2:41 am

So I poked at the resource building part a little bit. Looks like it can even build rpm's if given enough info. I don't know if it'll let me defined everything like I want it in my spec file, though. I'll have to look into that more. I made it work similar to wxLauncher's, so run the following to get my latest commit to attempt to generate a dmg or whatever the app bundle is. I'm not adding any data files or frameworks, so it isn't likely to find anything else it needs, but it'd be good to know if it's a start in the right direction.

Code: Select all

cmake -DCMAKE_BUILD_TYPE=Release -DDEVELOPMENT_BUILD=Off ..


On the frameworks note, the OSX dev stripped them all out of the tree with a comment about providing them externally. I wonder how he's doing that. I can script copying them from wherever, and hopefully cmake handles the rest.

Steel01
darklord42
Posts: 254
Joined: Sat Nov 17, 2007 3:01 am
Contact:

Re: A downstream Linux fork of d2x-xl

Postby darklord42 » Tue Jul 22, 2014 4:44 am

Well it compiles, but now the binary i got isn't viable, just sits open. Wonder what happened.

I tried the Xcode package, as is it needs some help finding the SDL libraries. Not sure what's going on there, but I take it the mac dev has a working one. Hopefully he will fix the one in the sourcecode

As to building an app bundle it actually turns out to be rather simple. Though you would have to add d2x-xl-mac folder back into your branch

I used otool to find out what librares are linked and where. Somehow the binary is already set to look for the libraries in the bundle. I have no idea how, but it's in the code somewhere.
The only problem is that SDL.framework is set to be found using @rpath which i don't agree with one bit. It would require a compiler flag at build time to defign which directories are in the rpath list. And is totally unnecessary. All the other libraries use @executable_path which looks for the libraries relative to the executable (OSX understands this). So i'd make SDL.framework do the exact same.

here basic script so you know what needs to be done

Code: Select all

mkdir ./d2x-xl.app
mkdir ./d2x-xl.app/Contents
mkdir ./d2x-xl.app/Contents/MacOS
mkdir ./d2x-xl.app/Contents/Frameworks
mkdir ./d2x-xl.app/Contents/Resources
mkdir ./d2x-xl.app/Contents/Resources/English.lproj
mv ./d2x-xl_782b1d4 ./d2x-xl.app/Contents/MacOS/d2x-xl
cp ../d2x-xl-mac/Resources/d2.icns ./d2x-xl.app/Contents/Resources
cp ../d2x-xl-mac/Resources/d2doc.icns ./d2x-xl.app/Contents/Resources
cp ../d2x-xl-mac/Resources/Info.plist ./d2x-xl.app/Contents
cp ../d2x-xl-mac/Resources/InfoPlist.strings ./d2x-xl.app/Contents/Resources/English.lproj
echo 'APPLD2XL' > ./d2x-xl.app/Contents/PkgInfo
cp -R /Library/Frameworks/SDL.framework ./d2x-xl.app/Contents/Frameworks
cp -R /Library/Frameworks/SDL_image.framework ./d2x-xl.app/Contents/Frameworks
cp -R /Library/Frameworks/SDL_mixer.framework ./d2x-xl.app/Contents/Frameworks
cp -R /Library/Frameworks/SDL_net.framework ./d2x-xl.app/Contents/Frameworks
install_name_tool -change @rpath/SDL.framework/Versions/A/SDL @executable_path/../Frameworks/SDL.framework/Versions/A/SDL ./d2x-xl.app/Contents/MacOS/d2x-xl


This is all providing we can get the binary to work again...

Few things:

Perhaps you can set it to copy the SDL frameworks wherever cmake finds it.
Also d2x-xl-782b1d4 from cmake appears to have that random number attached to it afterward. Is it always this or do we have to come up with a smarter mv command?
One more thing, If I'm using gcc from macports to build I would have to use a program called dylibbundler to add the opemmp dylib and other gcc stuff into the bundle. This would have to be done outside of cmake i think.

[EDIT] Turns out the framework files in the source code are empty, Why bother having empty libraries in the source code? Perhaps Diedel doesn't realize that these "files" are actually directories with an extension and not the libraries itself. Just like the App bundles are not the executable themselves.
Last edited by darklord42 on Tue Jul 22, 2014 5:12 am, edited 4 times in total.
Macbook Pro 6,2
Mac OS. 10.9.3
2.8 GHz Intel i7
8 GB RAM
GeForce GT 340M 512mb/Intel HD Graphics
Intel HD Audio
darklord42
Posts: 254
Joined: Sat Nov 17, 2007 3:01 am
Contact:

Re: A downstream Linux fork of d2x-xl

Postby darklord42 » Tue Jul 22, 2014 4:52 am

I found an issue when compiling with clang

In file included from /Users/herecomethej/d2x-xl/main/game.cpp:73:
/usr/local/include/SDL/SDL_syswm.h:58:10: fatal error: 'X11/Xlib.h' file not
found
#include <X11/Xlib.h>

Why is it suddenly trying to build with x11? we don't need this.
[edit]
Weird GCC doesn't seem to get it. (perhaps it's my macports install)
X11 is not installed by default anymore, but we don't wan't it anyway. Why is it looking for this?

It's right there in the SDL_syswm.h header, but we dont want it. I don't get it.
Macbook Pro 6,2
Mac OS. 10.9.3
2.8 GHz Intel i7
8 GB RAM
GeForce GT 340M 512mb/Intel HD Graphics
Intel HD Audio
steel01
Posts: 89
Joined: Mon Jun 02, 2014 11:44 am

Re: A downstream Linux fork of d2x-xl

Postby steel01 » Tue Jul 22, 2014 12:55 pm

So, does my latest commit generate a syntactically correct app bundle? I think cmake will handle most of what the script you posted itself. What I have up won't have any frameworks, though.

My cmake script on my fork will by default append the commit hash to the executable name. If you add -DDEVELOPMENT_MODE=Off to the cmake command, it will instead append the version number. Makes keeping multiple executable easier. CMake keeps track of that name. But the patches I submit upstream don't do that for legacy/consistency purposes.

I kinda agree with not having the frameworks in the source tree. You don't get updates or match system installed versions that way. If they need referenced, at worst they should be externals (per version control definition). I noticed one of your SDL includes is in /use/local, does the frameworks get installed somewhere in /use/local as well? Maybe I can import that way.

As for openmp with clang, I don't know that it's worth the trouble. If you can come up with an easily scriptable way that can dynamically detect if that method is available, I can merge it into the build system. But I have no easy way to write or test that myself.

Steel01

Edit: I'll take a look into the x11 thing, I don't know offhand. Bit isn't that coming from your SDL install?
darklord42
Posts: 254
Joined: Sat Nov 17, 2007 3:01 am
Contact:

Re: A downstream Linux fork of d2x-xl

Postby darklord42 » Tue Jul 22, 2014 1:52 pm

Apparently there is some SDL stuff on the system, but It could just as easily use the headers in the framework, As long as it's not linking to something there which it isn't. I wouldn't point cmake to the system /usr/ folder. (I'm not sure if that's default or some botched install on my part)
We want the SDL stuff to be embedded in the app bundle.

We would still have to get the compiled binary to use @executable_path for the SDL library and not @rpath, I doubt cmake does this. (though if the code is changing the libraries linkers, that is the way it should be there anyway)

-----------------------
I tried

Code: Select all

cmake -DCMAKE_BUILD_TYPE=Release -DDEVELOPMENT_BUILD=Off ..

and got

Code: Select all

CMake Warning (dev) at cmake/d2x-xl_installer.cmake:17 (add_custom_command):
  Policy CMP0040 is not set: The target in the TARGET signature of
  add_custom_command() must exist.  Run "cmake --help-policy CMP0040" for
  policy details.  Use the cmake_policy command to set the policy and
  suppress this warning.

  The target name "d2x-xl" is unknown in this context.
Call Stack (most recent call first):
  CMakeLists.txt:195 (include)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Error at cmake/d2x-xl_installer.cmake:66 (install):
  install TARGETS given target "d2x-xl" which does not exist in this
  directory.
Call Stack (most recent call first):
  CMakeLists.txt:195 (include)
at the end
-----
As for the Openmp stuff with gcc, dylibbundler scans the binary copies any dylibs associated with it to a specified folder in the app bundle and relinks the binary and libraries to each other in a portable manner, all in a single command. I don't think you want to have cmake ask for this utility as it would require a macports install, since I'm using macport's gcc, it doesn't matter anyway, and is very much a side thing. We really should focus on Clang being the main way to get this working. As that is what people will have.


As to X11, I could easily fix it on my system ln -s /opt/X11/include/X11 /usr/local/include . But I don't know if we want to do this... It shouldn't need it.
Macbook Pro 6,2
Mac OS. 10.9.3
2.8 GHz Intel i7
8 GB RAM
GeForce GT 340M 512mb/Intel HD Graphics
Intel HD Audio
steel01
Posts: 89
Joined: Mon Jun 02, 2014 11:44 am

Re: A downstream Linux fork of d2x-xl

Postby steel01 » Tue Jul 22, 2014 2:07 pm

Oh my, good job steel... Sorry, update and try again. Small typos might make this much more annoying since I can't completely syntax check myself.

Okay, question. Do you have a way to command line mount a DMG such as the SDL runtimes? On Linux, I have to jump a hoop by first decrypting those. But if you can script mount them, I might be able to script download, extract, compile against, and package into a bundle those frameworks.

As for cmake making a properly linked app bundle, doesn't wxlaunchers work fine?

Steel01
darklord42
Posts: 254
Joined: Sat Nov 17, 2007 3:01 am
Contact:

Re: A downstream Linux fork of d2x-xl

Postby darklord42 » Tue Jul 22, 2014 4:02 pm

Interesting, hdiutil does everything from mount to create disk images. Its basically Disk Utility on a command line.

http://osxdaily.com/2011/12/17/mount-a- ... -mac-os-x/

I updated and tried

Code: Select all

cmake -DCMAKE_BUILD_TYPE=Release -DDEVELOPMENT_BUILD=Off ..

and got:

Code: Select all

CMake Error at cmake/d2x-xl_installer.cmake:66 (install):
  install TARGETS given target "d2x-xl" which does not exist in this
  directory.
Call Stack (most recent call first):
  CMakeLists.txt:195 (include)

Am I suppose to do something else?
--------

Wxlauncher works, just fine. but somehow SDL.framework is being linked with @rpath which isn't ideal. I thought it was in the code, but I can't find it. Normally the xcode project does this when it builds the app. So therefore cmake must be the one doing this for us. Why it's using @rpath for the SDL.framework but not the others I don't get. I think rpath is set so it finds it both on the system and in the bundle which throws up a warning for the ambiguity. I don't know if it hurts anything, sometimes this does. But the binary doesn't launch anyway so it's hard to tell.
Macbook Pro 6,2
Mac OS. 10.9.3
2.8 GHz Intel i7
8 GB RAM
GeForce GT 340M 512mb/Intel HD Graphics
Intel HD Audio
steel01
Posts: 89
Joined: Mon Jun 02, 2014 11:44 am

Re: A downstream Linux fork of d2x-xl

Postby steel01 » Tue Jul 22, 2014 4:18 pm

No, I missed another spot. Update and try one more time. I think I got them all now... No guarantees something else won't fail, though. :roll:

Hdutil? Great, I'll look into that. Ummm... I suppose the next question is: can a user mount stuff?

If rpath checks the bundled frameworks, then it should be fine. If there is one installed systemwide, I would think it should override the programs built in one. That's me and my Linux style sentiments (use shared libraries for as much as possible).

Steel01
darklord42
Posts: 254
Joined: Sat Nov 17, 2007 3:01 am
Contact:

Re: A downstream Linux fork of d2x-xl

Postby darklord42 » Tue Jul 22, 2014 5:38 pm

hmm. everything in my build folder got replaced with a d2.icns...

this was the error

Code: Select all

Linking CXX executable d2x-xl_1.17.61
shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
Built target d2x-xl_1.17.61



Question. from where did it pull the d2.icns? the entire d2x-xl-mac folder is not in your branch. You would think you would need the Info.plist from that folder as well. and the d2doc.icns that it uses for d2x-xl files as referenced in that Info.plist.
The Info.plist contains all the registry info for the app bundle, as well as what is the name of the executable in the MacOS folder, the icon to use, asociated file extensions, their icons to use, and so on.


users can mount dmg images by just clicking on them. If you are looking to create dmg images make sure to use a compressed dmg for distribution.
---
regarding @rpath. you may be right. I don't like the warning it throws in the terminal when opened, but it's ok I guess. I like my terminal clean. if you can replace it with @executable_path/../Frameworks, I would.
Macbook Pro 6,2
Mac OS. 10.9.3
2.8 GHz Intel i7
8 GB RAM
GeForce GT 340M 512mb/Intel HD Graphics
Intel HD Audio
steel01
Posts: 89
Joined: Mon Jun 02, 2014 11:44 am

Re: A downstream Linux fork of d2x-xl

Postby steel01 » Tue Jul 22, 2014 6:05 pm

I thought cp was smarter than that. Rinse and repeat, should be fixed now. And the icns file is in the packaging directory. Along with the windows icn and fedora rpm spec files. The plist should be generated by cmake.

I'm wanting the build script to be able to download a DMG, mount it, and extract files. Without user interaction or asking for elevated privileges. That way, the frameworks can be set up without having them in the source tree.

Steel01
darklord42
Posts: 254
Joined: Sat Nov 17, 2007 3:01 am
Contact:

Re: A downstream Linux fork of d2x-xl

Postby darklord42 » Tue Jul 22, 2014 6:09 pm

I saw your comment, I don't think it's cp's fault. I already gave it a try, Besides, it is smarter then that :) Something is weird with ${APP_RESOURCES_PATH} it's not creating the directory system you want. And the rm -rf seems to clear everything in the build folder before hand. When it places the d2.icns file it places it directly in the build folder.

I gathered that Info.plist is generated, but there is quite a bit of stuff that has been put into the one we have that couldn't be generated. We would be missing the d2x-xl association with .pig .ham files for instance. (not a biggie but it looks nice) Or copyright/version info. Probably has some random hash as the package identifier. Not big to the end user but it doesn't look nice. Can cmake not copy the existing one?
Macbook Pro 6,2
Mac OS. 10.9.3
2.8 GHz Intel i7
8 GB RAM
GeForce GT 340M 512mb/Intel HD Graphics
Intel HD Audio
steel01
Posts: 89
Joined: Mon Jun 02, 2014 11:44 am

Re: A downstream Linux fork of d2x-xl

Postby steel01 » Tue Jul 22, 2014 6:27 pm

The resource path should be correct now. Yay for copy-pasta from wxlauncher. We'll get there eventually.

I noticed the copyright and file extension definitions. Copyright is set, but is different right now. It can be set to whatever. I'd have to look on the extension stuff.

Steel01
darklord42
Posts: 254
Joined: Sat Nov 17, 2007 3:01 am
Contact:

Re: A downstream Linux fork of d2x-xl

Postby darklord42 » Tue Jul 22, 2014 7:06 pm

mkdir: /Users/herecomethej/d2x-xl/build//d2x-xl.app/Contents: No such file or directory

slowly but surely :)

you got to create the d2x-xl.app and Contents folders first before you can make a Resources folder in them.
Macbook Pro 6,2
Mac OS. 10.9.3
2.8 GHz Intel i7
8 GB RAM
GeForce GT 340M 512mb/Intel HD Graphics
Intel HD Audio
steel01
Posts: 89
Joined: Mon Jun 02, 2014 11:44 am

Re: A downstream Linux fork of d2x-xl

Postby steel01 » Tue Jul 22, 2014 7:08 pm

In packaging/d2x-xl_installer.cmake, add -p right after mkdir on that line. See if that works.

Steel01
darklord42
Posts: 254
Joined: Sat Nov 17, 2007 3:01 am
Contact:

Re: A downstream Linux fork of d2x-xl

Postby darklord42 » Tue Jul 22, 2014 7:35 pm

Great now we got the d2.icns in the right place. it's a start :)
Now we have to create the d2x-xl/contents/MacOS folder and put the executable in that under the name d2x-xl
and then create the Info.plist into the Contents folder
Macbook Pro 6,2
Mac OS. 10.9.3
2.8 GHz Intel i7
8 GB RAM
GeForce GT 340M 512mb/Intel HD Graphics
Intel HD Audio

Return to “General Discussions”

Who is online

Users browsing this forum: No registered users and 1 guest