WIP new Portfile Bonzomatic

[artkiver (グレェ)]

Pending the merge of this PR: ​https://github.com/Gargaj/Bonzomatic/pull/177

I have begun prepping a Portfile for Bonzomatic.

I seem to be running into some issues with the cmake Portgroup's default destroot.target {install/fast}

Is there a way to override that?

Otherwise the build instructions from the upstream project are pretty straight forward, e.g.

mkdir build && cd build
cmake -DCMAKE_BUILD_TYPE=Release ../
cmake --build .

The cmake Portgroup seems to take care of the build and Release stuff more or less automatically.

I'm probably missing something simple, but I've been staring at cmake-1.1.tcl and experimenting with some different parameters without much improvement.

Attaching main.log and WIP Portfile for reference.

[artkiver (グレェ)]

WIP Portfile for Bonzomatic

[artkiver (グレェ)]

main.log after WIP Bonzomatic port -v install errored out.

[ryandesign (Ryan Carsten Schmidt)]

Replying to artkiver:

Pending the merge of this PR: ​https://github.com/Gargaj/Bonzomatic/pull/177

We don't want the CMakeLists.txt to set CMAKE_OSX_ARCHITECTURES at all because the portgroup already does that correctly. I don't remember if the portgroup will override what's in CMakeLists.txt. If it doesn't, what's in CMakeLists.txt will have to be removed with a patch.

I seem to be running into some issues with the cmake Portgroup's default destroot.target {install/fast}

Is there a way to override that?

Undoubtedly. Looking into the portgroup, it sets the default destroot.target to install/fast:

​https://github.com/macports/macports-ports/blob/d4eee4d269b1246d6d035d1bc5b08cb9bc659372/_resources/port1.0/group/cmake-1.1.tcl#L87

You can surely set destroot.target to something else in your Portfile if you want. It's surprising that that should be necessary however; as far as I know it's a standard cmake makefile target that should appear in all makefiles generated by cmake.

The CMakeLists.txt says this software requires C++14 when building on macOS so you'd better indicate that in the Portfile with compiler.cxx_standard 2014.

Strange homepage. Don't you think homepage the github portgroup sets for you is better?

[artkiver (グレェ)]

Replying to ryandesign: Thanks for taking a look at this!

Replying to artkiver:

Pending the merge of this PR: ​https://github.com/Gargaj/Bonzomatic/pull/177

We don't want the CMakeLists.txt to set CMAKE_OSX_ARCHITECTURES at all because the portgroup already does that correctly. I don't remember if the portgroup will override what's in CMakeLists.txt. If it doesn't, what's in CMakeLists.txt will have to be removed with a patch.

I appreciate that perspective. I was thinking along similar lines insomuch as it might be possible to build on PPC as well (though I haven't dug up one of my PowerBooks from storage to test, I suppose I can!). The initial impetus for the issue I submitted to the upstream project was when I went to build this from source on an Apple Silicon Mac, it was prompting me to install Rosetta (2) after launching, which shouldn't be necessary, though the PR I linked to previously maybe isn't the most appropriate way to handle such things for MacPorts either given we support more than just Intel and Apple Silicon.

I seem to be running into some issues with the cmake Portgroup's default destroot.target {install/fast}

Is there a way to override that?

Undoubtedly. Looking into the portgroup, it sets the default destroot.target to install/fast:

​https://github.com/macports/macports-ports/blob/d4eee4d269b1246d6d035d1bc5b08cb9bc659372/_resources/port1.0/group/cmake-1.1.tcl#L87

You can surely set destroot.target to something else in your Portfile if you want. It's surprising that that should be necessary however; as far as I know it's a standard cmake makefile target that should appear in all makefiles generated by cmake.

Yeah, I experimented with some different parameters for destroot.target but kept running into errors; I guess i still haven't wrapped my head around the install/fast default nor what a better alternative would be in this instance.

The CMakeLists.txt says this software requires C++14 when building on macOS so you'd better indicate that in the Portfile with compiler.cxx_standard 2014.

Ah, good catch! I'll update that.

Strange homepage. Don't you think homepage the github portgroup sets for you is better?

Very possibly! I contemplated that approach too; I think since this project has sort of evolved out of the demo-scene that is why it references the pouet.net page; but as far as code updates GitHub seems to be where development is actively taking place these days.

[ryandesign (Ryan Carsten Schmidt)]

Replying to artkiver:

Replying to ryandesign:

We don't want the CMakeLists.txt to set CMAKE_OSX_ARCHITECTURES at all because the portgroup already does that correctly. I don't remember if the portgroup will override what's in CMakeLists.txt. If it doesn't, what's in CMakeLists.txt will have to be removed with a patch.

I appreciate that perspective. I was thinking along similar lines insomuch as it might be possible to build on PPC as well (though I haven't dug up one of my PowerBooks from storage to test, I suppose I can!). The initial impetus for the issue I submitted to the upstream project was when I went to build this from source on an Apple Silicon Mac, it was prompting me to install Rosetta (2) after launching, which shouldn't be necessary, though the PR I linked to previously maybe isn't the most appropriate way to handle such things for MacPorts either given we support more than just Intel and Apple Silicon.

Ok, that proves the build is ignoring the architecture MacPorts is telling it to use, so we want to remove CMAKE_OSX_ARCHITECTURES from the CMakeLists.txt, not just for the potential of building on ppc/ppc64/i386 but also for the benefit of anyone trying to cross compile for arm64 on x86_64 or vice versa or anyone who wants to build universal.

[ryandesign (Ryan Carsten Schmidt)]

Replying to artkiver:

Replying to ryandesign:

Strange homepage. Don't you think homepage the github portgroup sets for you is better?

Very possibly! I contemplated that approach too; I think since this project has sort of evolved out of the demo-scene that is why it references the pouet.net page; but as far as code updates GitHub seems to be where development is actively taking place these days.

I'm just saying your current homepage is a discussion forum thread from 2018–19. It's formatted terribly, is hard to read, it doesn't say what Bonzomatic is or provide a link to the GitHub page or otherwise say how to get or use it. The GitHub page, on the other hand, does say what it is, has screenshots, has the code, has a link to the discussion forum thread for anyone wanting to read that.

[ryandesign (Ryan Carsten Schmidt)]

Replying to artkiver:

Replying to ryandesign:

I seem to be running into some issues with the cmake Portgroup's default destroot.target {install/fast}

Is there a way to override that?

Undoubtedly. Looking into the portgroup, it sets the default destroot.target to install/fast:

​https://github.com/macports/macports-ports/blob/d4eee4d269b1246d6d035d1bc5b08cb9bc659372/_resources/port1.0/group/cmake-1.1.tcl#L87

You can surely set destroot.target to something else in your Portfile if you want. It's surprising that that should be necessary however; as far as I know it's a standard cmake makefile target that should appear in all makefiles generated by cmake.

Yeah, I experimented with some different parameters for destroot.target but kept running into errors; I guess i still haven't wrapped my head around the install/fast default nor what a better alternative would be in this instance.

I guess this project does not provide an install target so you'll have to override the destroot phase (create a destroot {…} block) to do the installation manually.

According to ​the readme:

"The Bonzomatic.app bundle, resulting from the compilation, should be found in ./build/Bonzomatic.app. You can place it anywhere. We do NOT recommend putting it in /Applications. Bonzomatic is looking for config.json files and resources living at the same level of the app."

So, that's an unfortunate choice by the developers, since ${applications_dir} is of course where we would want to put applications, and they should fix their application not to look for other resources at the same level as the app. For example, perhaps those files should be in ~/Library/Preferences or ~/Library/Application Support or Bonzomatic.app/Contents instead.