[Piglit] libepoxy conversion v2

[Eric Anholt]

Jose Fonseca <jfonseca at vmware.com> writes:

> ----- Original Message -----
>> Jose Fonseca <jfonseca at vmware.com> writes:
>> 
>> > ----- Original Message -----
>> >> Ken Phillis Jr <kphillisjr at gmail.com> writes:
>> >> 
>> >> > On Mon, Feb 24, 2014 at 1:41 PM, Eric Anholt <eric at anholt.net> wrote:
>> >> >> I'd really like to get this in soon -- Fabian just spent what was
>> >> >> probably quite a bit of time building a new piglit-private dispatch
>> >> >> builder due to the .spec files no longer being updated, and I'd
>> >> >> rather we not waste anyone else's time.  I still haven't heard
>> >> >> anything from anyone using Windows, which is the only real risk I see
>> >> >> with this series.
>> >> >>
>> >> >
>> >> > Since I tend to use windows a bit I will go ahead and review the
>> >> > overall patch ( including libepoxy ).
>> >> >
>> >> > 1) Requiring unix-specific features to compile on windows will drive
>> >> > away developers. ( I am talking about the pkgconfig requirement ).
>> >> > It's not exactly a good idea to require this on windows.
>> >> > 2) libepoxy itself uses autogen and autoconf... This is an absolute
>> >> > nightmare for windows developers. I would like to suggest adding cmake
>> >> > build options to libepoxy ( Mainly to help improve the build process
>> >> > on systems that lack libepoxy and also make it easier to integrate
>> >> > within piglit itself )
>> >> 
>> >> Yeah, and cmake is a nightmare for linux developers.  (So is automake,
>> >> but cmake is worse).  Based on my experience in open source software so
>> >> far, I'm not expecting contributions from windows developers -- I'd be
>> >> happily surprised to get some, but I'm not waiting.  So "this will drive
>> >> away windows developers" ends up having basically no weight, compared to
>> >> me being able to get work done.
>> >
>> > That maybe fine for libepoxy, but this essentially means one of two
>> > things: 1) libepoxy is not suitable as a dependency to a
>> > cross-platform project like piglit , or 2) windows developers are not
>> > welcome on piglit.  I can't think of it in any other way.
>> 
>> Take a look at waffle -- a dependency of piglit that went out of its way
>> to make things easy to build the windows code necessary, including using
>> cmake for its build system.  Almost 2 years later, we've still got
>> piglit_glut_framework for windows, when glut is holding back modern
>> testing on Windows and making us have an extra abstraction layer on our
>> abstraction layer abstraction layer.
>> 
>> I just don't see windows graphics developers clamoring to work on this
>> stuff.
>
> True.  But you have to realize that waffle doesn't bring much benefit
> for Windows testing -- unlike Linux which has many GL flavours (GLX,
> EGL, desktop GL, ES GL, and a few more), on Windows there is only one
> de-facto flavour of GL (desktop GL through WGL).
>
> Yes, we can go and add support for waffle to work on Windows, but the
> only benefit is cleanup, or more truthfully, to be good citizens among
> piglit community.
>
> And it's not that we're sitting on it on purpose. We have an endless
> to-do list, and I didn't imagine that the current abstraction was a
> burden, hence it wasn't quite near the top, at least of my list.
>
> But to be perfectly honest, if you insist or give an ultimatum we'll
> be forced to do something about it.  Windows support in Piglit is
> important.

I'm not trying to issue an ultimatum about waffle here -- I'm not that
interested in it.  I'm just trying to show why my estimate of the
probability of scaring away a potential contributor to epoxy is so low.

>> But beyond that, here's my problem.  Even if someone shows up with a
>> pile of cmake for epoxy for MSVC builds, I still need to be able to
>> turn out binaries for releases, since that's what normal windows
>> developers want, from what I've heard.  So I'd need a MSDN
>> subscription to do MSVC builds.  That's not something I have, nor am
>> I interested in pursuing it unless we just can't get an open
>> toolchain to generate working binaries.
>
> I personally don't have much interest in windows binaries FWIW.  I
> tend to slap things into a continuous integration server, and build it
> from source continuously. It may cost time initially, but it pays off
> on the long term, as I can rebuild everything from scratch when
> upgrading MSVC, or avoid broken builds when one component suddenly
> requires the latest version.
>
> But if you'd want libepoxy to be contender against GLEW (i.e., a
> general purpose library for GL apps), then yes, I think you'd need to
> do something along those lines.

Yep, killing GLEW is definitely a goal of the project.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20140307/015ae092/attachment.pgp>