[Piglit] libepoxy conversion v2

[Eric Anholt]

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.

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

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.
-------------- 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/cc1ee315/attachment.pgp>