[05:15:11] --- Brandon Allbery has left [05:15:41] --- Brandon Allbery has become available [07:30:51] --- deason has become available [08:08:19] --- dev-zero@jabber.org has left [10:54:34] --- Simon Wilkinson has become available [10:55:43] README-WINDOWS is still mentioning 1.5 tarballs as more likely to build than nightly snapshots. Is the rest of it still expected to be reasonablye accurate for the 1.7 world? [10:57:01] I think I have built Windows using approximately the instructions in that file [10:57:25] But Asanka configured my build environment, so there may have been magic there that I didn't know about [10:57:31] Okay. [10:57:41] I guess I will just give it a shot and holler if things look broken... [10:57:51] That's probably the best bet [11:02:31] --- Simon Wilkinson has left [12:07:44] there is no one right way of building the windows clients but there are lots of wrong ways. README-WINDOWS does not attempt to document all of the combinations of visual studio, sdks, and ddks that work for each of the various build architectures. README-WINDOWS probably does not document all of the docbook dependencies which are statisfied by cygwin. I recommend 1.7.18-1 or later because Cygwin recognizes afs symlinks after that release. OpenAFS 1.7 is built with VS2008, SDK 6.1 and DDK 7600. OpenAFS 1.6 was built with VS2005, and older SDK and DDK 6001 OpenAFS master will build with the same tool chain as 1.7 but the next release series is likely to be built from either VS2010 or VS2012 and not support XP as that is no longer supported by VS2012. OpenAFS master requires the Secure Endpoints Kerberos Compatibility SDK 1.0 to provide a translation layer for the various Kerberos products. Master does not build against the KFW SDK in the OpenAFS tree. The hardest part about setting up a windows build environment is making sure that you are using a consistent set of headers, libraries and merge modules. [12:09:39] Well, my main goal for a windows build environment is "ensure that I don't horribly break everything". But I figure it's best to start off with a source tree that is known to work (i.e., a released 1.7 tarbal). [12:10:19] My scratch VM that already has a KfW build environment has VS2010 and SDK 7.0. [12:10:54] Oh, and I have WiX 3.mumble (README-WINDOWS says to use the 2.x series). [12:11:04] Wix3 will not work [12:11:21] Okay, then. I guess I'm pulling up a new VM for openafs stuff. [12:12:54] We don't build with VS2010 or SDK 7 because those versions cannot be used to build binaries compatible with Win2000 [12:12:55] Do you think that using VS2010 to build 1.7 will cause headaches? [12:13:04] probably [12:13:27] Okay, I'll try to dig around for older versions. Thanks [12:13:32] MSDN [12:13:41] I'm sure MIT still has a subscription [12:13:48] Yes. [12:32:59] if you are only trying to ensure that things have not been broken, my suggestion would be to only run the "install" step and test your binaries by manual replacement of the ones you care about. If you are modifying rx, replace afsrpc.dll and reboot. Don't worry about the entire install tree. Just make sure that the version number you are building 1.7.x matches the other binaries. You can mix debug and release binaries. The roken allocator will be used by all of the dlls and exes. [14:43:00] --- Simon Wilkinson has become available [15:34:19] --- dev-zero@jabber.org has become available [15:36:15] --- deason has left [15:45:07] --- dev-zero@jabber.org has left [16:48:56] --- Simon Wilkinson has left [17:32:53] --- Brandon Allbery has left [17:33:04] --- Brandon Allbery has become available [23:29:57] --- Simon Wilkinson has become available