Haiku support #2697
Haiku support #2697
Conversation
extrowerk
force-pushed
the
haiku_support
branch
from
76140a2 to
a10636c
Compare
|
I was thinking of removing support for BeOS2000 in the source of master and I'm wondering how much this will affect the PR if you could provide me with some data |
|
Afaik not at all, but let me look a bit better into this. |
|
@KalleZ : Haiku defines just HAIKU and not BEOS, so every code guarded by only ifdef BEOS could be deleted. |
|
Thank you for checking, I will most likely cook up a patch tonight so it should be simple to fix merge conflicts e.g. getrusage() |
|
@miqlas Please see my review comment too, seems like you are missing an extra & to prevent a build failure |
|
@KalleZ : thanks, but i don't see your review comment. Where is it? |
|
@KalleZ : looks ok to me. Thanks for cleanup. |
|
I'm using TortoiseGit on Windows which does most of these issues for me in a GUI, but this Stackoverflow article should help you on the CLI: |
|
@KalleZ : i think i solved it, thanks for your help. |
|
The Travis failure is unrelated to this, so don't be afraid, as Travis is often giving the wrong impression :) If you scroll to the bottom of the failed job, you can see its a SOAP test that fails |
|
@KalleZ: i just tested your BeOS cleanup commit yesterday, everything fine. |
|
@remicollet Any comments on this one? No problems with ifdefing code, but I'm a bit apprehensive about the buildsystem changes. Especially the added checks for |
configure.ac
Outdated
| @@ -416,6 +416,7 @@ dnl are usually in libnsl | |||
| dnl Also, uClibc will bark at linking with glibc's libnsl. | |||
|
|
|||
| PHP_CHECK_FUNC(socket, socket) | |||
| AC_CHECK_LIB(network, socket) | |||
There was a problem hiding this comment.
You could amend the preceding PHP_CHECK_FUNC() instead.
PHP_CHECK_FUNC(socket, socket, network)
|
Any news here? |
|
Hi, is the patch all completed and well tested on your end? |
|
@KalleZ : better to test it again completly. I'll report back. |
|
@nikic @remicollet still any concerns with the build system changes? |
|
@KalleZ : tested the patches, looks ok on Haiku. |
|
Any news here? |
|
I'd see the build system change indeed questionable, too, while the code change should be fine. Couldn't the path's topic be solved through symlinking, etc.? Also reading this https://www.haiku-os.org/blog/kallisti5/2017-10-09_where_is_haiku_r1/ , looks like Haiku has to confront with more serious challenges than web development right now. Thanks. |
|
@weltling huh? Just because some developers are off dealing with bigger problems doesn't mean that developers entirely unconnected to those problems (like @extrowerk here) can't work on other things. So I don't see how that's relevant. Also no, the paths topic cannot be solved through symlinking. Haiku's main system hierarchy is read-only due to how our package manager works (and in a HaikuPorter chroot, things are even more locked down than normal, so symlinks could not even be added through another package.) |
|
@waddlesplash it is great someone still finds time to work on things. And of course things like Haiku is interesting. The issue i'd personally see right now, and that's why i linked that blog previously - the change with new paths is quite intrusive while the OS itself is still establishing the basic things. Once a patch is merged, is has to be supported by the PHP community, where the target status seems uncertain still :( If summing that up, it is concerning, as for me. Are similar patches pushed to other projects, like postgres, cairo, glib, etc.? Could you link to them? Thanks. |
Well, the path change occurred back in 2013 with the merge of the package manager. That was the last real "basic thing", and mostly all of the things in that blogpost are infrastructural (package buildbots vs. manual package building, etc.)
Yes: lighttpd, Rust, Swift, QEMU, Mono (although incomplete), libgit2, FreePascal, SDL2 (has had support since the BeOS days), Qt has had support for some years now, LMMS, mGBA. And I can find even more if you want... |
|
Thanks for the links. Yep, for small libs it doesn't look that huge. I was also doing some research and found https://github.com/haikuports/haikuports. It looks like there's already some PHP version with a similar patch included https://github.com/haikuports/haikuports/tree/master/dev-lang/php. I then went to check some other libs from haiku ports, too. Fe primarily it was interesting other software depending on same libs as PHP and what it requires. It turned out, fe that there's also gnupg and git, that depend on libcurl. Libcurl is listed as required in their *.recipe files, but i don't see any patches regarding licurl neither in the ports repo nor in the mainstream regarding Haiku. Same for example if looking at odt2txt and its libzip dependency. So the question that I immediately had - what is specifically different between PHP and those examples, that requires such an explicit patch for paths? Or in general, some ports list libs as a requirement, the build scripts are similar m4, but some projects in the ports using same libs are not patched at all neither in the core nor upstream. Thanks. |
|
Libs and headers are usually available in the default search paths, configure checks the presence of libs and headers, eventually with pkg-config. PHP doesn't seem to follow this method which makes hard coded paths required. It would be indeed better to avoid hard coded paths. |
|
Status on this? I've been working on haikuports recipes for > 7.1.x Thanks everyone for all the hard work and planning to date on this! |
|
This appears to have gone stale, so closing this. |
|
FWIW in the meantime PHP has switched to using pkg-config for most libraries, so this is probably mostly resolved at this point. If someone is still interested in this, I think it's okay to add ifdefs for haiku where necessary -- the main problematic part here were the ad-hoc build system changes. |
|
the current patchset at Haikuports is rather minimal: |
No description provided.