Jose Fonseca <[email protected]> writes: > ----- Original Message ----- >> Jose Fonseca <[email protected]> writes: >> >> > ----- Original Message ----- >> >> Ken Phillis Jr <[email protected]> writes: >> >> >> >> > On Mon, Feb 24, 2014 at 1:41 PM, Eric Anholt <[email protected]> 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.
pgpylDTGifAZv.pgp
Description: PGP signature
_______________________________________________ Piglit mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/piglit
