FreeBSD Port: some questions to the project

[clausecker]

Greetings.

I am currently in the process of building a port for the FreeBSD Ports Collection for this project. In accordance with our policies, I need to unbundle as many dependencies as feasible and wire configuration options through to port options / flavours.

The following dependencies are planned to be unbundled: squirrel, duktape, lua, zlib, giflib, libuv, http-parser, libpng, SDL.

We will not build libretro plugins; that may be a future package.

Here are some questions to you:

• the project has the option to build the PRO version by setting an option. I plan to wire this option through into the port so users can decide to build the PRO version when compiling the port themselves. Binary packages of the PRO version will not be available. I can also make it so that the PRO version is a flavour, meaning that binary packages of both version will be available. What is your recommended best practice?
• the project builds a bunch of extra binaries that are not installed by the cmake scripts. Do I understand correctly that you do not intend to have them shipped in binary distributions?
• there is an option BUILD_DEMO_CARTS to build some demo applications, but it doesn't seem to affect the installed tic80 binary in any way. I plan to always unset this option. Is this correct?
• there is an option BUILD_WITH_MRUBY to build with mruby. I do not understand how mruby is used in TIC-80 and your instructions do not mention it. I plan to always unset this option and not offer mruby. Is this correct?
• there is an option to use the sdlgpu library, however it is disabled by default. Would you like us to offer using it as an option?

Thank you for your help in these matters. The port has otherwise progressed quite nicely and can likely be released as soon as I get responses.

[clausecker]

I've also noticed a number of warnings that could be addressed:

/usr/home/fuz.ports/emulators/tic-80/work/TIC-80-1.0.2164/src/api/wasm.c:1015:34: warning: format specifies type 'int' but the argument has type 'IM3Environment' (aka 'struct M3Environment *') [-Wformat]
    printf("deiniting env %d\n", env);
                          ~~     ^~~
/usr/home/fuz.ports/emulators/tic-80/work/TIC-80-1.0.2164/src/api/wasm.c:1065:44: warning: format specifies type 'int' but the argument has type 'tic_core *' [-Wformat]
    dbg("Initializing WASM3 runtime %d\n", core);
                                    ~~     ^~~~
/usr/home/fuz.ports/emulators/tic-80/work/TIC-80-1.0.2164/src/api/wasm.c:26:25: note: expanded from macro 'dbg'
#define dbg(...) printf(__VA_ARGS__)
                        ^~~~~~~~~~~
2 warnings generated.

Here, %p would be the correct directive.

/usr/home/fuz.ports/emulators/tic-80/work/TIC-80-1.0.2164/src/studio/studio.c:776:44: warning: unsequenced modification and access to 'x' [-Wunsequenced]
    else if (x < 2 / d1)    return n1 * (x -= 1.5 / d1) * x + 0.75;
                                           ^              ~
/usr/home/fuz.ports/emulators/tic-80/work/TIC-80-1.0.2164/src/studio/studio.c:777:44: warning: unsequenced modification and access to 'x' [-Wunsequenced]
    else if (x < 2.5 / d1)  return n1 * (x -= 2.25 / d1) * x + 0.9375;
                                           ^               ~
/usr/home/fuz.ports/emulators/tic-80/work/TIC-80-1.0.2164/src/studio/studio.c:778:44: warning: unsequenced modification and access to 'x' [-Wunsequenced]
    else                    return n1 * (x -= 2.625 / d1) * x + 0.984375;
                                           ^                ~
/usr/home/fuz.ports/emulators/tic-80/work/TIC-80-1.0.2164/src/studio/studio.c:2092:49: warning: result of comparison of constant 256 with expression of type 'u8' (aka 'unsigned char') is always true [-Wtautological-constant-out-of-range-compare]
    if(tic->input.mouse && !m->relative && m->x < TIC80_FULLWIDTH && m->y < TIC80_FULLHEIGHT)
                                           ~~~~ ^ ~~~~~~~~~~~~~~~
4 warnings generated.

Behaviour of this code is undefined. It should probably be fixed.

[Anrock]

there is an option BUILD_WITH_MRUBY to build with mruby. I do not understand how mruby is used in TIC-80 and your instructions do not mention it. I plan to always unset this option and not offer mruby. Is this correct?

The wiki lists ruby as one of supported languages. I guess it's just main site is a bit behind.

[nesbox]

the project has the option to build the PRO version by setting an option. I plan to wire this option through into the port so users can decide to build the PRO version when compiling the port themselves. Binary packages of the PRO version will not be available. I can also make it so that the PRO version is a flavour, meaning that binary packages of both version will be available. What is your recommended best practice?

I think PRO binaries shouldn't be available, only compiled by users.

the project builds a bunch of extra binaries that are not installed by the cmake scripts. Do I understand correctly that you do not intend to have them shipped in binary distributions?

Yes, we release one tic80 binary file only, the other files are tools or something else.

there is an option BUILD_DEMO_CARTS to build some demo applications, but it doesn't seem to affect the installed tic80 binary in any way. I plan to always unset this option. Is this correct?

Yes, you can, for example it's disabled by default in Android and WASM builds.

there is an option BUILD_WITH_MRUBY to build with mruby. I do not understand how mruby is used in TIC-80 and your instructions do not mention it. I plan to always unset this option and not offer mruby. Is this correct?

User won't be able to play carts made with Ruby in this case, I would recommend you set this option by default.

there is an option to use the sdlgpu library, however it is disabled by default. Would you like us to offer using it as an option?

Yes, it would be great to have such option.

Thank you and sorry for delay with the response :)

[clausecker]

Thank you for your responses. I have submitted a tentative version of the port: emulators/tic-80 and will update it according to your comments in the next weeks. For this we first need to port sdlgpu, which may be slightly tedious.