On 5 February 2018 at 22:14, kallisti5 <kallis...@unixzen.com> 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
>>> 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 :-)
Seems like an extra L was added where it's not needed. Namely I
mentioned pthread (notice the lack of L)
For a while gcc/clang has worked on unifying all the pthread platform
specifics behind the -pthread toggle.
Some specifics include: presence/lack of a separate library, -D_REENTRANT,
>>> -- Alex
>> Hi Alex,
>> I have a branch for building haiku with meson, when I was trying to
>> 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
>> 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
> ends up looking like spaghetti. Here is what our current build does:
> It looks like Jerome hacked in a patch for autotools... but i've heard some
> of instability with the resulting artifacts.
AFAICT Jerome's work was fine, modulo the "let's do everything at
once" which tends to bite us all.
Can you please send that over, even if there's a meson support in the works.
Two is better than none ;-)
mesa-dev mailing list