[OpenAFS-win32-devel] Winafsbld

Jeffrey Altman jaltman@secure-endpoints.com
Mon, 29 Nov 2010 17:23:25 -0500


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--