Re: Winafsbld
Jeffrey Altman <[email protected]> Mon, 29 Nov 2010 17:23:25 -0500
| Newsgroups | gmane.comp.file-systems.openafs.devel.win32 |
|---|---|
| Organization | Secure Endpoints Inc. |
| Message-ID | <[email protected]> |
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2047737D648DA5183B4DD476 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11/29/2010 3:39 PM, Mickey Lane wrote: > I really like the idea of having all of the environment variables assoc= iated >with a particular product clearly indicate that they're part of that product. >It greatly reduces the risk of having one product walk all over another.= >Everything used by winafsbld starts with WINAFSBLD_. The risk here is quite small. The OpenAFS build system is not an application that is being installed on your system. There is no reason to publish these environment variables as global to the system. As long as winafsbld is outside of the OpenAFS distribution you can think of it as a product of its own. However, once it is integrated into OpenAFS it is no longer a separate product and it no longer makes sense to duplicate variables in the environment block. > Winafsbld is written to use the existing makefiles without any changes;= >I didn't think I'd get very far trying to rename a bunch of things in th= e >existing files for no good reason. And for good reason. OpenAFS is built in house by a number of organizations. Many of these organizations drop the openafs source tree into a much larger build system for which the build environment configuration is already specified. Such orgs do not make use of ntbuild.bat nor would they use winafsbld. >=20 > If we can make something useable for everyone out of winafsbld, >cleaning up the naming disconnects would be very high on my list of to-d= os. It isn't very high on mine. Both because doing so would unnecessarily break the building of OpenAFS for organizations that do build it for themselves but also because there are so many more important things that affect end users. Creating the ntbuild.bat derivatives really isn't all that hard. We do it once and then are done. Where critical time is required is the replacement of afs_config.exe with a MMC, improving the integration with the explorer shell, making the perl and java bindings build on Windows, and much more. As I said in the gerrit 3332, these improvements are mostly going to affect newbies but newbies have a much more serious problem. They can't obtain the development tool chain that is required to build OpenAFS in the first place. Not without spending more than $1200 per year on a MSDN Professional subscription. Getting the core binaries to build with just the SDK/WDK compiler would be a much more important benefit to the newbies. Jeffrey Altman --------------enig2047737D648DA5183B4DD476 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJM9CffAAoJENxm1CNJffh4wWMIANsv3uu5xy3gwsXX5qdqQpdK C4vKwCvAnVkJSAAMzeF9OVq2P9CkSyissBVEjfv1JHo6SupoBXpXSJcX5nraK1WQ /4qXKUYwGhVAe5htubsIhK70jRrxgGa8qhsfV7jjxCo1f9vtih/KUv5JDoAFkTKE 2d+dXafJpLIfa3biDidlTCjI4hcaknUMux9oDoaG0k8WxT4TxsM4Anu+Czm2kb42 GFCFXo7/9oS/S+dm3uREItCJIkd9aWjG8FbyCKPGhC0BfEmDpCpnLxM74k0ylB45 JpAHsgUg+/DwIdoAvrmB27ZhYJHt5Zgf0JmZXjqxo0rTCOeU40lmw4/bdMk/T+I= =vbcQ -----END PGP SIGNATURE----- --------------enig2047737D648DA5183B4DD476--