Config/settings directory?

Development Third-Party
1

As an exercise in making Protrekkr more Haiku-friendly, I’m trying to move the configuration file from ./ptk.cfg to ~/config/settings/protrekkr_config but it seems to be read-only. How am I doing this wrong? Code fragment follows:

// ------------------------------------------------------
// Set default configuration path
#if defined(__HAIKU__)
#define ALLOCATE_CONFIGNAME char *FileName = "~/config/settings/protrekkr_config";
#define GENERATE_CONFIGNAME
#else
#define ALLOCATE_CONFIGNAME char FileName[MAX_PATH];
#define GENERATE_CONFIGNAME sprintf(FileName, "%s" SLASH "ptk.cfg", ExePath);
#endif

// ------------------------------------------------------
// Save the configuration file
void Save_Config(void)
{
    FILE *out;
    char extension[10];
    char Temph[MAX_PATH];
	ALLOCATE_CONFIGNAME
    int i;
    int Real_Palette_Idx;
    char KeyboardName[MAX_PATH];
    signed char phony = -1;

    sprintf(extension, "PROTCFGG");
    Status_Box("Saving 'ptk.cfg'...");

    GENERATE_CONFIGNAME
	
    memset(KeyboardName, 0, sizeof(KeyboardName));
    sprintf(KeyboardName, "%s", Keyboard_Name);

    out = fopen(FileName, "wb");
1 Like
2

~ isn’t understood by fopen, it’s interpreted by the shell when you use it on the command line!

3

Please don’t try to hardcode this.

There is a dedicated API. Please use it.

https://www.haiku-os.org/docs/api/FindDirectory_8h.html

4 Likes
4

Adding to this: Some examples from HaikuPorts Wiki.

2 Likes
5

I finally got around to fixing this. Look forward to getting a pull request to HaikuPorts soon.

6

Looks cool! Reminds me of cubic player.

7

Well it builds on x86_64 and runs, I can’t seem to get the recipe to build under x86 even using setarch x86 on my QEmu image.

@Begasus , could you look at the recipe at haikuports/media-sound/protrekkr/protrekkr-2.7.0git.recipe at master · SamuraiCrow/haikuports · GitHub and tell me why it is broken on x86?

8

@SamuraiCrow, you don’t need to manually use setarch if you’re using haikuporter. But you need to invoke it differently: haikuporter protrekkr_x86 so it knows you want the secondary arch, and not the primary one.

9

Thanks! I’ll try that!

10

I’ve got conflicting definitions of int32_t within the 32-bit version of the code. One is typedef resolved to __haiku_std_int32, and the other identically named typedef resolves to __haiku_int32. It looks like one is from stdlib and the other is from POSIX. Oddly, a seemingly identical solution for int64_t works flawlessly. Now what?

11

You are mixing “int32” and “int32_t”. On haiku these are different types due to historical BeOS choices. I guess protrekkr tries to define its own int32 type. But on Haiku it can’t do that, because the type is defined in our system headers. So you have to remove the definition on protrekkr side

1 Like
12

Without checking the recipe* maybe try to #ifdef HAIKU and #include <SupportDefs.h> for that definition (it works for other places where I’ve seen these conflicting types)?
You could run a search for this at haikuports for some examples.

Strike the above, checked a build on 32bit, worked out OK, launches fine.

A few changes (mostly cosmetic) would be needed for the recipe, also no Deskbar link yet, icon set, binary rename?

EDIT: looked like I pulled in the wrong version for the recipe, the branch you still have has an older version and the new one seems to be in master branch?

I’m getting a bit confused also, I now see 3 different sources, the old recipe still in the repo points to the one from falkTX, you got one here, and there is still the original upstream …

EDIT2: this fixes it for both arch’s:

From a264ebf4b063625a55a7ff5c7a22ecf50b39293c Mon Sep 17 00:00:00 2001
From: Begasus <begasus@gmail.com>
Date: Fri, 1 Nov 2024 09:27:00 +0100
Subject: Fix build for both arch's


diff --git a/src/files/include/files.h b/src/files/include/files.h
index 6ec0f3d..b9f8436 100644
--- a/src/files/include/files.h
+++ b/src/files/include/files.h
@@ -37,7 +37,7 @@
 #include <stdio.h>

 #include "../../include/variables.h"

 

-#if defined(__AROS__) || defined(__MORPHOS__) || defined(__HAIKU__)

+#if defined(__AROS__) || defined(__MORPHOS__)

 #include <stdint.h>

 #include <string.h>

 #define int32 int32_t

diff --git a/src/include/variables.h b/src/include/variables.h
index 7c99924..50b65c7 100644
--- a/src/include/variables.h
+++ b/src/include/variables.h
@@ -352,6 +352,7 @@ typedef struct
 #if defined(__HAIKU__)

 #include <stdint.h>

 typedef int32_t int32;

+#define int64 int64_t

 #endif

 

 // ------------------------------------------------------

-- 
2.45.2

The conflict was because Haiku’s int32 was defined in 2 places, using the one in variables.h solves it (as int32 was already there, was just missing the one for int64).

1 Like
13

@Begasus and @PulkoMandy

Thanks! I knew there were conflicting definitions but I didn’t know from the error text where the other one was! I’ll change the one in variables.h to fit.

1 Like
14

Around the lines of the error you probably should see a “first defined here” which lead me to variables.h. :slight_smile:

1 Like
15

It looks to me, that the POSIX include is given preference by LibSDL1.2.x over the C standard library. I hope that I don’t have to patch SDL_Config.h in that package just to get the 32 bit Haiku version to work.

16

Quick check went fine here, could play some of the included files in the list when this is launched. (on both arch’s)