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. > 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.
pgprAlt_p6GyT.pgp
Description: PGP signature
_______________________________________________ Piglit mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/piglit
