[beports] Re: Haiku APR Port
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: beports@xxxxxxxxxxxxx
- Date: Tue, 06 May 2008 16:41:08 +0200
On 2008-05-06 at 13:33:04 [+0200], Andreas Färber <andreas.faerber@xxxxxx>
wrote:
>
> Since you've just subscribed, could you please take a look at the list
> archive; I've posted a patch for review against gnulib (same as
> currently in our SVN and linked from the Wiki), disabling two BeOS
> #ifdef sections in stdbool.in.h. If there are no objections until
> tomorrow (when Scott should be back), I'll post it to the gnulib list.
Having looked only at the patch, not the original file, I guess it's fine.
I'm more and more convinced that we should drop the __BEOS__ macro for
Haiku's gcc, though. From what I've seen so far there are probably less
BeOS specific patches one wants to keep for Haiku than those one wants to
avoid.
> Concerning your POSIX quest, one question: I had the impression that
> Haiku's native threading mechanism is the Be one and that pthreads
> were only a wrapper around the Be implementation, added later for
> POSIX compatibility. Is this impression wrong, i.e. is it "safe" and
> just as performant to switch native Be code to generic Unix code where
> both exist?
> I thought I heard Axel saying the Be threads were superior to
> pthreads... (if that were the case, you couldn't dump APR's beos
> directories completely but would need to extend my approach of
> #include'ing the generic Unix files from within the BeOS directories)
There is of course a bit of overhead involved in using pthreads instead of
BeOS native threads, but that's not really relevant. Most pthread functions
are just small wrappers calling the respective native thread function. For
APR the point is totally moot, since the APR thread API closely resembles
the pthread API. So the only difference that using the native vs. pthread
API in APR makes is where the used wrapper code lives -- in libapr or in
libroot. The obvious advantages in using pthreads are thus, that libapr
will be smaller and the wrapper code we use in libroot is potentially more
efficient, since we can use private API where we consider it beneficial.
> In some place in APR I already have disabled some more BeOS network
> code from within the beos dir. While perhaps inferior to your approach
> (which does require knowledge of Haiku's inner workings!), mine has
> the advantage of making it work at all today: Not all tests pass, but
> all my patches have been uploaded via my patched Subversion on Haiku,
> and virtually all repositories used for the various ports have been
> checked out under Haiku using the ported tools.
That's nice, of course, though the R5 net server svn should also work. At
least there have been reports that it is possible to crash Haiku using it
for bigger checkouts. :-P
> But thanks for notifying us of your plans, then I assume I should not
> post APR/neon/Subversion patches upstream for now?
Yes, that would nice.
> Or did you already
> spot some things that can be shared between the two porting
> approaches?
Not yet at least. I've looked through your current patch, but besides some
lines from the configure.in or build/apr_hints.m4 there's little that would
apply, since I don't intend to define BEOS or use the BeOS specific code at
all.
> (Not sure what you refer to as smooth, it did take some
> time for some simply, undisputable BeOS patches to be committed, as
> posted recently.)
Well, my original patch was > 100 KB, which caused it to be bounced by the
mailing list. Zipping it didn't work either, since the list would accept
text attachments only. In the end I sent it to David Reid, who said he
would review and commit it. He started to commit a few parts, but later
asked me to split the patch up, which I didn't bother to do.
> I certainly welcome any POSIX work of yours on Haiku, I guess I'm
> gonna need it for Mono!
Yeah, that's a big plus -- better POSIX compliance will definitely make
ports easier. I'm quite pleased about how well that worked for OpenSSH. The
current patch is only a few lines telling the build system what libs and
header directories to use. François' patch for BONE is about 25 KB and
doesn't even enable all features.
> Please keep us up-to-date on your progress,
Will do.
> I'll add an entry to the
> APR Wiki page later on and would like to link to your patches,
> assuming you'll post them in Haiku SVN.
I can move the patches here just as well. I put them in Haiku's repository
only because that was easiest for me at that time. I'm totally fine with
helping to further HaikuPorts as *the* official place for porting stuff to
Haiku.
> Your APR 1.0.1 patch we could
> either link to or archive in our SVN.
OK, I'll have a look where I can put it.
CU, Ingo
--
BePorts homepage - http://tools.assembla.com/BePorts
List archives: //www.freelists.org/archives/beports
Administrative contact: brecht@xxxxxxxxxxx
Other related posts:
