On Thu, May 14, 2009 at 04:58:02PM -0700, Rush Manbert wrote: <snip> > I have two questions: > > 1) Why doesn't libevent as released just build in Visual Studio if > this was so easy to accomplish for me? Or have I missed something?
I don't maintain libevent, but I'd guess any issues exist for the same reasons I've encountered in my own projects. _Patching_ to support a platform like Win32+VS is easy. _Maintaining_ the patch/port is quite a headache. Especially so regarding Visual Studio--as opposed to a simple MinSYS make(1) port--because the build system is probably never used by the lead maintainers. And in my short, punctuated experience w/ Visual Studio, the config system changes faster than even autotools' rate of churn (and I'm no fan of autotools). (Plus, it's common these days for environments to host a plethora of autotools version combinations, but because of the monolithic IDE paradigm of Visual Studio, this isn't feasible for typical Windows developers.) > 2) I would be happy to provide a patch that adds this support. Are any > of the developers interested in receiving it? Afraid of commitment? (Just kidding.) If libevent still doesn't build out-of-the-box, despite the endless submissions of patches to fix [apparently] broken builds over the years, I suspect the only tenable solution is for somebody to step up and either manually or automagically build from the tree on a regular basis (weekly?), or to fork a Windows branch which tracks the development branch, similar to how Portable OpenSSH tracks OpenBSD's OpenSSH. In my projects, I typically only attempt to support make(1). (GNU Make if I'm lazy, or the project is too big.) But this allows me to focus on using a mingw-gcc cross-compiler to verify builds and Wine to run regressions. The best VS patch to libevent would be one which somehow automates the process similarly. Alternatively, maintain a port uses CMake--or something similar--which might ultimately get pulled into mainline. But you'll need significant buy-in (i.e. have done a very polished job) from the leads, I think. Lastly, ditching Visual Studio support altogether--instead relying on MinSYS and make(1)--and simply maintaing a binary Visual Studio archive might work better. But unless it's kept up-to-date on a very regular basis, it'll be hard to placate a developer's need/greed for the latest, greatest, just-fished-out-of-the-water code (a near universal ailment ;) _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
