On 2018-02-05 16:14, kallisti5 wrote:
On 2018-02-05 15:39, Dylan Baker wrote:
Quoting kallisti5 (2018-02-05 12:58:30)
On 2017-10-24 11:47, Emil Velikov wrote:
> Hi Jerome,
>
> On 23 October 2017 at 16:58, Jerome Duval <jerome.du...@gmail.com>
> wrote:
>> * configure.ac:
>> -pthread is not available on Haiku.
>> Haiku doesn't require --enable-dri
>> build hgl on Haiku
>> * egl/Makefile.am: define backendfiles for Haiku
>> * src/gallium/Makefile.am: build winsys/sw/hgl, state_trackers/hgl and
>> targets/haiku-softpipe on Haiku.
>> * src/gallium/targets/haiku-softpipe: add Makefile.am
>> * src/gallium/state_trackers/hgl: add Makefile.am
>> * winsys/sw/hgl: add Makefile.am
>> * src/hgl/Makefile.am: add Makefile.am
>> ---
> Thanks for the patch. I think Eric has a point regarding splitting this
> up.
> Here is one way to handle it:
> - patch 1 - the driver, aka st/hgl + sw/hgl + targets/haiku
> - 2 - src/egl
> - 3 - src/hgl
> - 4 misc fixes (the SoftwareRenderer.cpp hunk?)
> - 5 toggle - configure.ac + src/Makefile.am
Hm, it looks like Jerome never got back to work on these changes...
let
me try to
pick up the ball and run with it.
> Couple of small suggestions:
> - keep all the sources and headers in the sources lists in
> Makefile.sources
> - how do you guys manage pthreads - please mention that in the commit
> message.
>
> If I'm reading this correctly, you strip out -pthread and there's no
> pthread-stubs on Haiku.
Haiku (and BeOS for that matter) has pthread support built into its
core
libroot.so.
No need for -lpthread, all applications can assume its presence.
Things
that link -lpthread actually fail due to a non-existant libpthread...
*however* as i'm typing this i'm being told we recently implemented a
dummy static libpthread.a to try and appease assumptions about
-lpthread
existence.... so i'll remove the pthread checks :-)
-- Alex
Hi Alex,
I have a branch for building haiku with meson, when I was trying to
compile
neither the scons build nor the autotools build seemed to compile on a
Haiku VM
instance (x86_64), that was a few months ago though, so maybe its
fixed.
Our plan is to remove autotools from mesa, probably this year. I'm
thinking if
things look pretty good through the 18.0 release cycle I'll probably
propose
marking autotools as deprecated for 18.1 and propose removal in 18.2.
Ah. crap. I just got autoconfig working :-). Historically I have only
used
SCons for our builds. I always preferred the SCons build since
autotools always
ends up looking like spaghetti. Here is what our current build does:
https://github.com/haikuports/haikuports/blob/master/sys-libs/mesa/mesa-17.1.4.recipe#L52
It looks like Jerome hacked in a patch for autotools... but i've heard
some reports
of instability with the resulting artifacts.
I'm not going to block you guys using autotools or NAK anything, I
just want
you to be aware that we're trying to consolidate down to just meson
and
android.mk files. I can respin the haiku patches and CC you if you're
interested in
looking at them.
If Meson is the future, i'm definitely down helping (or even taking
over) that branch
if it is just incomplete Haiku work.
I'm going to try and do better maintenance on Haiku Mesa in 2018. I've
been only around
minimally in 2017 am a little out of date.
You might also want to see if you guys can update your meson, at least
last time
I checked it was 0.42, and I fixed the pthreads stuff in 0.43 so that
-pthread
and -lpthread are never added by meson.
I just installed meson on Haiku and we are currently at 0.43.0
I took a quick crack at meson on Haiku. Getting stuck with a -pthread
getting injected
somewhere around glapi gen.
Lets see if my modifications are close to yours sight unseen :-)
https://gist.github.com/kallisti5/eb43162dd4c9e61b5740444d20955118
-- Alex
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
