[Kfwdev] Using the checked in build configuration file

[Kevin Koch]

1) The config file on the command line _is_ used - to locate the sources in
the repositories.  bootstrap.xml is an example.

2) Of course the config file in the sources can't know where to put the
sources (src) or results (out).  That's what /SRC and /OUT are for.

3) What led Sam to the conclusion that the config file in the build should
be used for building the release is:  

<paraphrase> How were the sources built?  The command line is not recorded.
The config file can come from anywhere.  It could have set bogus environment
variable values, for example.  The wrong repository tags could have been
specified.  By putting the config file in the sources, you control and
document exactly what was built and how. </paraphrase>

Here is an example of how to exactly reproduce a build:
 
Get yourself a krb5/src/windows/build area.  [At some point it will be
stable and it won't matter which one.]

Use this handy kfw320beta3.xml, which contains the cvs and svn tags:

bkw.pl /CONFIG kfw320beta3.xml /U user

If you don't like the defaults for where the sources are put (C:\KfW) or
where the built results are written (C:\KfW\public), then do this instead:

bkw.pl /CONFIG kfw320beta3.xml /U user /SRC <source path> /OUT <result path>


All you need to reproduce a build now are the repository tags.
kfw320beta3.xml is a convenience.  You could just as easily do

bkw.pl /REPOSITORY CHECKOUT -U user /CVSTAG kfw-3_2_0_beta3 /SVNTAG
kfw-3_2_0_beta3


All this being said, the change has been reverted, as requested.

Kevin
 
-----Original Message-----
From: Jeffrey Altman [mailto:jaltman at secure-endpoints.com] 
Sent: Thursday, April 19, 2007 9:22 AM
To: kpkoch at mit.edu
Cc: kfwdev at mit.edu
Subject: Re: [Kfwdev] Using the checked in build configuration file

Kevin Koch wrote:
>
> Last night Jeff tried to use the automated build, bkw.pl, specifying a
> config file.  He was surprised when the build used the config file in
> the sources he checked out.
>
What is the point of specifying a config file if it doesn't get used?

How is the model that you have implemented usable to accomplish the
required goal?

Building KFW at the moment requires two executions of the script:

Pass One:

   1. Empty the specified source directory <src> and check <repository =
      checkout> out sources from specified tags <cvstag> <svntag>
      <svnbranch> and locations <CVSROOT> <SVNURL> as user <username>
   2. Build <make = 1> sources <src>
   3. Log data output to <logfile> with <verbose> content
   4. Generate install packages <package> but do not sign <sign = 0>
   5. Using the environment variables which are defined <KH_RELEASE>,
      <NODEBUG>, etc.
   6. Put the results in the output directory for MIT (unsigned binaries
      and installers) as specified by <out>

Pass Two:

   1. Do not clean or checkout <repository = skip> sources  <src>
   2. Do no build <make = 0> sources <src>
   3. Log data output to a different <logfile> with <verbose> content
   4. Generate install packages <package> and sign <sign = 1> all
      binaries and install packages
   5. Using the environment variables which are defined <KH_RELEASE>,
      <NODEBUG>, etc.
   6. Put the results in the output directory for Secure Endpoints
      (signed binaries and installers) as specified by <out>

This is what I have been attempting to do for more than a month with
your scripts. 
>
>  
>
> This is exactly the design.  The configuration used to build the
> sources is part of the sources.
>
The configuration in the build tree is supposed to be used when the user
is doing something with the sources as exported by the zip file.    How
is it possible for the build tree to contain the configuration required
by MIT and Secure Endpoints?
>
>  
>
> If bkw.pl were to use the command line config file for the build,
> there wouldn't be any point in ever trying to use the config in the
> sources.  The command line config file would prevail and we'd be back
> to where we were two weeks ago.
>
I do not understand what this statement is supposed to mean.  Two weeks
ago we had build scripts that simply didn't work.  We also had build
scripts that required that every parameter be specified on the command
line for the script.  It was agreed that the command line would be
simplified and all of the configuration data would go into the
configuration files. 
>
> It sounds like more control over config files is needed.  What about
> two modes?  One is the current design and implementation - use the
> command-line-specified config file to locate the sources and the
> config in the sources to drive the build.  Two is to always use the
> command-line-specified config file.
>
How can the config file in the sources be used to drive the build?

   1. the config file in the sources doesn't know where the sources
      are.  It assumes they are located at C:\KfW and that the output is
      going to C:\KfW\public.  The C: drive is not where I am building
      from and C:\KfW is not where most people would unzip the source
      files for a given release.
   2. Not to mention that all of the other parameters will be wrong

What lead you to the conclusion that the config file in the build should
be used for building the release?

Have you really considered the usability of your solution given the
scenario that we have been discussing for the last few months?

Jeffrey Altman
Secure Endpoints Inc.