Who is working on the Godot port?

Show me please, where: https://build.haiku-os.org/buildmaster/master/x86_64/logviewer.html?buildruns/2543/builds/12592.log

Sidenote: You may want to review your dependency on GLEW 1.13 versus GLEW 2.1. :zipper_mouth_face:

Here^^
@extrowerk

This was on my last night’s build using last night’s git pull. This was from two days ago, but still present last night. I did a fresh work directory.

I can only say: works for me, and for the builder bot, so you have to find what’s wrong on your side. For reference: here is the current buildbot log, you can compare it with your output (note: i just updated the port 2 times today,and the bot building it right now, so maybe it isn’t finished yet):

https://build.haiku-os.org/buildmaster/master/x86_64/logviewer.html?buildruns/2550/builds/12597.log

1 Like

Thanks. I’ll look at it after work tonight.

Btw, you should delete your work folder before relaunching the build.

1 Like

Thanks. I’ve been doing that.

Build finished, and maybe i’m blind, but according to the output, the bot doesn’t even tried to compile the stream_peer_openssl.cpp file. So you have to find the culprit, i can’t help.

My bad, it did compiled that file. Sorry, Firefox said there is no “ssl” in the log.

I’ll check I out. I tried commenting out the call that failed in the source, but it failed later in the SSL part on something else when I did that.

Looking through some of the Godot forums, I found that it might be possible to link against the native SSL instead of Godot’s. It seems that they only put it in their tree to avoid dependency hell. Haiku is on the same version. Would that be a change in scons or the porter recipe? If I knew which to look in, I’d look into it. I’m thinking some of our problems may be due to rebuilding stuff that already has a haiku recipe. It should be a simple matter of changing where we link from in these cases.

No idea what native lib means in this context.

Usage of libs from separate packages called “system provided” or “shared” or “external”, while the the other way would be the use of the in-tree version, which referred as “in-tree” or “static”.

You may should reread my answers, where i stated it uses the one provided by the openssl package.

But frankly, it isnt a HaikuPorts support forum, if you got a problem with the current recipe/patchset, open a new issue at github.

Native->system provided or shared is what I’d link against. Fair enough on reporting to the git page. Thanks for the help and work so far! On a positive note, I tested a little of Godot’s command line functionality this morning. The latest build in HaikuDepot now has running GDscripts from the command line working. I ran a simple hello world, and it worked!!! This failed on the previous builds.

1 Like

With the latest 3.0.6-4 recipe, I got it building. Aside from an occasional status report in here to promote community interest, I’ll direct all future bug/development issues on this to github.com/haikuports.

1 Like

Now it’s time to have Godot working on my Haiku installation! I have an idea for a video game about BeOS / Haiku for so long … it could be the right time with the right tool chain to develop it 100% within Haiku.

1 Like

We could definitely use some help getting the Godot engine bugs worked out over at HaikuPorts on GitHub. I’m in the same boat. I want this toolchain on Haiku. If you’re willing, we could use more eyes in the code.

2 Likes

Good day,

I tried that too last year with 3.0.6, by means of HaikuPorts using the recipe available, and by means of using scons. No success, mostly because I lack the knowledge to do such things and time is limited.

Nonetheless, I would also appreciate having a working Godot on Haiku 64bit, but for now, after my experience on porting I only can help with emotional support :slight_smile:

Then again, once it works, should need to convince Godot devs to allow export to Haiku execs. One step at a time, though.

Regards,
RR

At least the recipe is in HaikuPorts, but there seems to be some patches as well, so it’s probably not upstream yet.


Was working on godot 3.1.1 a few days ago to patch it up. Decided to bump to godot 2.1.5.

NOTE:

  • godot 2.1.5 and 3.1.1 are current as of today.
  • godot 2.1.4 compiled and tested by miqas/Begasus/humdinger.
  • godot 3.0.6_x86 was packaged earlier but removed due to some issues.
  • godot 3.0.6 produced a push_decl_scope error w/ g+±x86 8.0.3 (x86, hrev53230 - reviewing).
  • godot 3.0.6 x86_64 packaged in HaikuDepot but has issues.

Work done:

5 Likes

Good day,

@cocobean you are the best… I will try as soon as I have time to… though I presume I will have issues due to video driver… you did what I couldn’t achieve!!! Great News!!!

Regards,
RR

Good day,

Well, while Godot working in Haiku is becoming stable, I’ve been working on something related too. As I wasn’t able to get Godot working on Haiku, at least I got GDScript highlight working on Koder:
screenshot1

So when Godot is ready, we can also use Koder to write GDScript code.

GDScript support for Koder will be merged soon.

Regards,
RR

4 Likes