VOGONS


Compile SVN in macOS?

Topic actions

Reply 120 of 172, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Yes, that's about all the difference there is 😉

Btw, another nice side effect of changing the glide.cpp is that if you have libglide2x in the same folder as the dosbox binary, it will just work when you doubleclick dosbox in Finder 😉
(If you don't have libglide in /usr/local/lib that is)

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 121 of 172, by almeath

User metadata
Rank Member
Rank
Member
Dominus wrote on 2021-03-13, 11:47:

Yes, that's about all the difference there is 😉

Btw, another nice side effect of changing the glide.cpp is that if you have libglide2x in the same folder as the dosbox binary, it will just work when you doubleclick dosbox in Finder 😉
(If you don't have libglide in /usr/local/lib that is)

I think you just answered by edited question above, thanks. 😀

DOSBox SVN for macOS (x86-64) - customized with Munt MT-32, Nuked OPL3, 3dfx Voodoo, Extra RAM, Large HD, and more.
https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS

Reply 122 of 172, by almeath

User metadata
Rank Member
Rank
Member

I have a quick question .. the list of patches to my SVN fork is growing, and some of these patches required substantial modifications to work on the Mac. It will be time consuming to have to manually re-apply them when I want to update the SVN source.

What is currently the easiest way to make diff patches on the Mac? Will I have to resort to command line tools? Currently I am using Github desktop to make and upload changes to the source.

I made sure that each patch was pushed to origin with an individual commit.

DOSBox SVN for macOS (x86-64) - customized with Munt MT-32, Nuked OPL3, 3dfx Voodoo, Extra RAM, Large HD, and more.
https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS

Reply 123 of 172, by emendelson

User metadata
Rank Oldbie
Rank
Oldbie

@almeath - This goes back to the "launcher" inside your app bundle.

Instead of the launcher executable, create a script named something like "Wrapper" with these contents:

#!/bin/bash

cd "$(dirname "$0")"
cd ../Resources
./dosbox/dosbox -conf dosbox_settings.conf -conf dosbox_launch.conf

After you create it, use chmod +x to make it executable, and move it into your MacOS folder.

Then rename your app bundle "Wrapper" and change the executable name in the info.plist to "Wrapper". Now, when you launch the app bundle, you will get the same result that you got with your original app.

The trouble with this is that the script needs to have the same name as the bundle and the same name has to be in the info.plist, and users can't be counted on not to change the name of the bundle. But maybe it's an idea worth playing with?

Reply 124 of 172, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator
almeath wrote on 2021-03-13, 14:19:

I have a quick question .. the list of patches to my SVN fork is growing, and some of these patches required substantial modifications to work on the Mac. It will be time consuming to have to manually re-apply them when I want to update the SVN source.

What is currently the easiest way to make diff patches on the Mac? Will I have to resort to command line tools? Currently I am using Github desktop to make and upload changes to the source.

I made sure that each patch was pushed to origin with an individual commit.

So you got each patch self contained if I understood your last sentence correctly?
Make sure you keep it that way and just script applying each patch.
There is a SVN command to clean it but you might as well script it to delete your SVN copy and check it out fresh.
(There it comes handy to keep one copy for playing around with tests and one that is only used to build your patched version).

There is another way involving to have to clone Dosbox SVN to git and then do that for each new commit and then rebase your changes. I'm not sure that is the right solution for you (definitely not for me).

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 125 of 172, by almeath

User metadata
Rank Member
Rank
Member
emendelson wrote on 2021-03-13, 14:46:

The trouble with this is that the script needs to have the same name as the bundle and the same name has to be in the info.plist, and users can't be counted on not to change the name of the bundle. But maybe it's an idea worth playing with?

Thanks for that suggestion. That was in fact the same reason I decided to stay with the launcher, as I quite often want to change my info.plist and bundle names. I will definitely look into this though.

The approach I take is to have a pre-built wrapper, and then duplicate it to create new game wrappers, which necessitates changing the internals of the wrapper, including the info.plist and bundle name. So the suggested approach probably would not work for my purposes, but if there was to be a script created to automatically package up a game, then that would be different. 😀

Last edited by almeath on 2021-03-13, 15:07. Edited 2 times in total.

DOSBox SVN for macOS (x86-64) - customized with Munt MT-32, Nuked OPL3, 3dfx Voodoo, Extra RAM, Large HD, and more.
https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS

Reply 126 of 172, by almeath

User metadata
Rank Member
Rank
Member
Dominus wrote on 2021-03-13, 14:56:
So you got each patch self contained if I understood your last sentence correctly? Make sure you keep it that way and just scrip […]
Show full quote

So you got each patch self contained if I understood your last sentence correctly?
Make sure you keep it that way and just script applying each patch.
There is a SVN command to clean it but you might as well script it to delete your SVN copy and check it out fresh.
(There it comes handy to keep one copy for playing around with tests and one that is only used to build your patched version).

There is another way involving to have to clone Dosbox SVN to git and then do that for each new commit and then rebase your changes. I'm not sure that is the right solution for you (definitely not for me).

Yes, I believe they are all self contained. The former approach does sound more appealing. I will look into this, thanks.

DOSBox SVN for macOS (x86-64) - customized with Munt MT-32, Nuked OPL3, 3dfx Voodoo, Extra RAM, Large HD, and more.
https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS

Reply 127 of 172, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Forgot to mention, the reason to keep them self contained is that you don't have to figure out which patched functionality is the culprit if it were one big patch that fails to apply.

We need the recap guy from the Ant-Man movie to recap this thread 😉

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 128 of 172, by almeath

User metadata
Rank Member
Rank
Member
Dominus wrote on 2021-03-13, 15:16:

Forgot to mention, the reason to keep them self contained is that you don't have to figure out which patched functionality is the culprit if it were one big patch that fails to apply.

We need the recap guy from the Ant-Man movie to recap this thread 😉

Ha ha, true. Yeah, I made a mistake with one large patch for the 8GB hard drive size, and had to adjust it, but the rest were done in one commit each.

I am actually just not sure how to go about scripting this stuff, but will research it. It is too bad Github desktop does not provide a feature to help convert commits into diff files.

DOSBox SVN for macOS (x86-64) - customized with Munt MT-32, Nuked OPL3, 3dfx Voodoo, Extra RAM, Large HD, and more.
https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS

Reply 130 of 172, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

another fix for the libglide2x.dylib loading:

#elif defined(MACOSX)
hdll = dlopen("@executable_path/libglide2x.dylib", RTLD_NOW);
if (!hdll)
hdll = dlopen("libglide2x.dylib", RTLD_NOW);
#else

with this it will first try to open the dylib next to the dosbox binary and if that is not working it will use the old way.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 131 of 172, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
checking for X... libraries , headers

You're good, the configure scripts detected X and no additional defines were required for headers and libs.
The GL definition is not part of the X. On Linux, that's from MESA, I believed. Perhaps you could try getting mesa from the homebrew, too. If the homebrew provides separate packages for runtimes and devel, then you could try with only the devel.

You can also try searching for a simple GL/GLX colored triangle sample C code and see if it will compile with your existing XQuartz/OpenGL setup.

Reply 132 of 172, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

> It is too bad Github desktop does not provide a feature to help convert commits into diff files.

When viewing a commit:

file.php?mode=view&id=105233

Slap a ".diff" on the end of the URL and ...

file.php?mode=view&id=105234

.. it'll give you the plain-text diff (handy for scripting too).

Also works for entire PRs (of multiple commits) to produce multi-file diffs.

Attachments

  • 2021-03-13_19-32.png
    Filename
    2021-03-13_19-32.png
    File size
    138.09 KiB
    Views
    648 views
    File license
    Fair use/fair dealing exception
  • 2021-03-13_19-30.png
    Filename
    2021-03-13_19-30.png
    File size
    195.48 KiB
    Views
    648 views
    File license
    Fair use/fair dealing exception
Last edited by krcroft on 2021-03-14, 04:13. Edited 1 time in total.

Reply 133 of 172, by almeath

User metadata
Rank Member
Rank
Member

Wow, that is a neat trick .. exactly what I needed, thanks! Quick and easy. 😀

DOSBox SVN for macOS (x86-64) - customized with Munt MT-32, Nuked OPL3, 3dfx Voodoo, Extra RAM, Large HD, and more.
https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS

Reply 134 of 172, by almeath

User metadata
Rank Member
Rank
Member
Dominus wrote on 2021-03-13, 17:44:
another fix for the libglide2x.dylib loading: […]
Show full quote

another fix for the libglide2x.dylib loading:

#elif defined(MACOSX)
hdll = dlopen("@executable_path/libglide2x.dylib", RTLD_NOW);
if (!hdll)
hdll = dlopen("libglide2x.dylib", RTLD_NOW);
#else

with this it will first try to open the dylib next to the dosbox binary and if that is not working it will use the old way.

Is it possible to have two fall backs? i.e. first it looks in the current directory, then perhaps I could have it look relative to the executable under Resources/lib/glide (to work within my preferred package structure), and lastly looking for the system level install? I could then combine that with your earlier install_name_tool suggestion to make sure that only one copy of SDL 1.2.0 is needed in the package. I just think that within a package structure it is tidier to have the glide dylibs in the lib directory with all the others. If that cannot be made to work I would stick with my current approach of having the dylib fallback specified in my script.

DOSBox SVN for macOS (x86-64) - customized with Munt MT-32, Nuked OPL3, 3dfx Voodoo, Extra RAM, Large HD, and more.
https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS

Reply 135 of 172, by almeath

User metadata
Rank Member
Rank
Member
kjliew wrote on 2021-03-13, 22:24:
You're good, the configure scripts detected X and no additional defines were required for headers and libs. The GL definition is […]
Show full quote
checking for X... libraries , headers

You're good, the configure scripts detected X and no additional defines were required for headers and libs.
The GL definition is not part of the X. On Linux, that's from MESA, I believed. Perhaps you could try getting mesa from the homebrew, too. If the homebrew provides separate packages for runtimes and devel, then you could try with only the devel.

You can also try searching for a simple GL/GLX colored triangle sample C code and see if it will compile with your existing XQuartz/OpenGL setup.

Thanks for those suggestions .. I will report back if I can make further progress with them. Just a quick question.. what outputs am I expecting from the build? I.e. I see the glide2x and 3x .la files, but I am not sure how those would be made to work with DOSBox given that it expects .lo and .dylib files for Linux and Mac respectively.

DOSBox SVN for macOS (x86-64) - customized with Munt MT-32, Nuked OPL3, 3dfx Voodoo, Extra RAM, Large HD, and more.
https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS

Reply 136 of 172, by almeath

User metadata
Rank Member
Rank
Member

Almost there with qemu-xtra, having installed Mesa with Homebrew*, and separately editing the window.cpp header to provide the right X11 location ( /opt/X11/include/X11 ).

*I had to copy in a glu.h file from my X11 install (don't know if that's advisable or not?)

It is now only failing due to this error:

ld: symbol(s) not found for architecture x86_64
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [libglide3x.la] Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** [libglide2x.la] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

DOSBox SVN for macOS (x86-64) - customized with Munt MT-32, Nuked OPL3, 3dfx Voodoo, Extra RAM, Large HD, and more.
https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS

Reply 137 of 172, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
almeath wrote on 2021-03-14, 04:28:

Just a quick question.. what outputs am I expecting from the build? I.e. I see the glide2x and 3x .la files, but I am not sure how those would be made to work with DOSBox given that it expects .lo and .dylib files for Linux and Mac respectively.

I am not really well-versed in the art of configure scripts. They are the same from the very old upstream OpenGlide CVS with minor additions to produce another Glide3x library. The format of objects and libraries should be resolved by itself by native compiling, otherwise there are serious issues with the build environment.

Reply 138 of 172, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator
almeath wrote on 2021-03-14, 04:19:
Dominus wrote on 2021-03-13, 17:44:
another fix for the libglide2x.dylib loading: […]
Show full quote

another fix for the libglide2x.dylib loading:

#elif defined(MACOSX)
hdll = dlopen("@executable_path/libglide2x.dylib", RTLD_NOW);
if (!hdll)
hdll = dlopen("libglide2x.dylib", RTLD_NOW);
#else

with this it will first try to open the dylib next to the dosbox binary and if that is not working it will use the old way.

Is it possible to have two fall backs? i.e. first it looks in the current directory, then perhaps I could have it look relative to the executable under Resources/lib/glide (to work within my preferred package structure), and lastly looking for the system level install? I could then combine that with your earlier install_name_tool suggestion to make sure that only one copy of SDL 1.2.0 is needed in the package. I just think that within a package structure it is tidier to have the glide dylibs in the lib directory with all the others. If that cannot be made to work I would stick with my current approach of having the dylib fallback specified in my script.

yes, that is actually not a problem, now that I figured it out 😀

#elif defined(MACOSX)
hdll = dlopen("@executable_path/libglide2x.dylib", RTLD_NOW);
if (!hdll)
hdll = dlopen("@executable_path/../lib/glide/libglide2x.dylib", RTLD_NOW);
if (!hdll)
hdll = dlopen("libglide2x.dylib", RTLD_NOW);
#else

and the loader path for the install_name_tool should be

@loader_path/../libSDL-1.2.0.dylib

(that is if you still have the dosbox binary in Resources/dosbox and libglide in Resources/lib/glide)

HOWEVER I have not found a way to have the bundle find the glide2x.ovl inside itself. The @loader/executable way does not work for the way this is being used. It works fine however with the glide2x.ovl being in the game folder.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 139 of 172, by almeath

User metadata
Rank Member
Rank
Member
Dominus wrote on 2021-03-14, 19:50:

HOWEVER I have not found a way to have the bundle find the glide2x.ovl inside itself. The @loader/executable way does not work for the way this is being used. It works fine however with the glide2x.ovl being in the game folder.

Thanks Dominus, I have updated my source on Github to reflect this patch. I tested it out and it now works with only the one copy of SDL 1.2.0 dylib inside the wrapper. 😀

I was not aware that it would have been possible to point the Glide dylib to the ovl file. I have left a copy inside the wrapper in the C drive so that it will be available for individual game installations.

DOSBox SVN for macOS (x86-64) - customized with Munt MT-32, Nuked OPL3, 3dfx Voodoo, Extra RAM, Large HD, and more.
https://github.com/almeath/DOSBox-SVN-64-bit-for-macOS