[Piglit] libepoxy conversion v2

[Jose Fonseca]

----- 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. 

> > BTW, using cmake+ninja  addresses many of issues experience while using
> > cmake+make.  E.g.:
> 
> cmake+ninja does dodge cmake's incompetent makefile generator (though it
> means I carry around a local makefile in my tree to get my normal editor
> integration to work).
> 
> But then there's the broken configure caching that makes it so you have
> to git clean regularly, and the broken library directory handling.  I
> mean, look at the workarounds in chad's "[Piglit] [ANNOUNCE] waffle >=
> 1.3 required, you may need to rerun CMake".  This build system is
> totally broken.

My experience has been less bad.

I have several cmake projects on a continuous integration server (piglit, apitrace, mesademos, etc), and I seldom need to do anything.  Builds are always incremental, after every git change, and it just works. 

On the other hand, I need to do `git clean` (and use ccache to compensate) on Mesa make build after every commit to prevent things consistently broken. (It has been like that for several years, so maybe thins are better nowadays.)

> 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.

Jose