System.Data.SQLite

Login
This project makes use of Eagle, provided by Mistachkin Systems.
Eagle: Secure Software Automation

Artifact 4360f7d3cbbe6b3439852a5b05b0d1df875621cc:


<title>Build Procedures</title>

<h2>Build Procedures</h2>

<p>
Follow these steps to build a new release of System.Data.SQLite (SDS).
Unless otherwise noted, all steps need to be done in the order specified.
</p>

<p>You will need a Visual Studio 2008, 2010, or 2010 SP1 development environment for this build.</p>

<p>
Thanks to the hard work of Joe Mistachkin, the build environment has been setup
using modular solution and property files.  SQLite.NET.2008.sln is the top level solution
for VS2008 and SQLite.NET.2010.sln for VS2010.  In general, files with 2008 in the 
name (eg. SQLite.Interop.2008.vcproj) or files ending in .vsprops are 
project and property files for the VS2008 solution.  Files with 2010 in the 
name (eg. SQLite.Interop.2010.vcxproj) or files ending in .props are 
property and project files for the VS2010 solution.  When making changes, 
you should make changes to both to keep them in sync.
</p>

<p>
You can either manually build the SDS using the supplied Visual Studio solutions,
or follow the steps outlined in the Build Automation section below.
</p>

<h2>Build Assumptions</h2>
<ol>
  <li>
    We want to ship managed binaries that rely on the .NET Framework 2.0
    SP2.  The .NET Framework 2.0 is very widely deployed and binaries produced for it can
    also be referenced and used successfully from projects using the .NET Framework
    4.0.
  </li>

  <li>
    We want to ship native binaries that rely on the Visual C++ 2008 SP1
    Runtime.
  </li>

  <li>
    We do not want to ship the "monster DLL" (i.e. the "mixed-mode"
    System.Data.SQLite.dll that includes native and managed code).  This
    will make it far simpler to maintain and ship the included core SQLite code
    (in the file "SQLite.Interop.dll").
  </li>

  <li>
    The machine used to prepare the official releases will have the
    [http://www.microsoft.com/downloads/en/details.aspx?FamilyID=ab99342f-5d1a-413d-8319-81da479ab0d7 | .NET Framework 3.5 SP1]
    and the corresponding [http://msdn.microsoft.com/en-us/windowsserver/bb980924.aspx | SDK] installed.
  </li>

  <li>
    The machine used to prepare the official releases will have [http://www.jrsoftware.org/isdl.php | Inno Setup 5.4.2]
    or higher installed in "%ProgramFiles%\Inno Setup 5" or
    "%ProgramFiles(x86)%\Inno Setup 5" for an 64-bit machines.  Alternatively,
    the InnoSetup directory may be included in the PATH environment variable.
  </li>

  <li>
    The string "&lt;root&gt;" represents the root of your source tree for
    System.Data.SQLite.
  </li>
</ol>

<h2>Build Automation</h2>

<ol>
  <li>Make sure the version information is correct for SQLite in the following
  files:

  <ul>
    <li>&lt;root&gt;\SQLite.Interop\props\sqlite3.vsprops</li>
    <li>&lt;root&gt;\SQLite.Interop\props\sqlite3.props</li>
  </ul>

  You'll need to update the SQLITE_MANIFEST_VERSION and SQLITE_RC_VERSION properties.
  This version number should track the release versions of SQLite 
  (ie. [http://www.sqlite.org/changes.html | 3.7.x]).
  </li>

  <li>Make sure the version information is correct for System.Data.SQLite in
  the following files:

  <ul>
    <li>&lt;root&gt;\SQLite.Interop\props\SQLite.Interop.vsprops</li>
    <li>&lt;root&gt;\SQLite.Interop\props\SQLite.Interop.props</li>
    <li>&lt;root&gt;\SQLite.Interop\src\win\interop.h</li>
    <li>&lt;root&gt;\Setup\set_common.bat</li>
  </ul>

  You'll need to update the SQLITE_MANIFEST_VERSION and SQLITE_RC_VERSION properties
  in the .vsprops and .props files, the INTEROP_VERSION define in interop.h,
  and the VERSION environment variable in set_common.bat.
  This version number should track the release versions of the System.Data.SQLite packages
  (ie. [./news.wiki | 1.0.x]).
  </li>

  <li>Make sure the "&lt;root&gt;\bin" and "&lt;root&gt;\obj" directories are completely
  free of all output files.  In theory, you could simply delete these directories;
  however, the file "&lt;root&gt;\bin\test.exe." is presently in the source tree.  I have
  no idea why; however, it's been there since 2005 [557ac901aff91f5da6bc7634ee1c75988ea9dec9].
  </li>

  <li>Open a normal command prompt window with "cmd.exe".</li>

  <li>Change the current directory to "&lt;root&gt;\Setup".</li>

  <li>Enter the following command to build the binaries for Win32 (x86):

  [./build.wiki#build.bat | build.bat] ReleaseNativeOnly Win32
  </li>

  <li>Make sure everything succeeds with no errors; the log file
  "%TEMP%\System.Data.SQLite.Build_ReleaseNativeOnly_Win32_Unknown.log"
  may be checked if any errors should occur.</li>

  <li>Enter the following command to build the binaries for x64:

  build.bat ReleaseNativeOnly x64
  </li>

  <li>Make sure everything succeeds with no errors; the log file
  "%TEMP%\System.Data.SQLite.Build_ReleaseNativeOnly_x64_Unknown.log" may
  be checked if any errors should occur.</li>

  <li>Enter the following command to build the setup binaries for Win32 AND
  x64 (unfortunately, it is not possible to build the setup using the
  InnoSetup GUI.  It must be done using the provided command line tools due to its dynamic
  nature):

  bake_all.bat
  </li>

  <li>Make sure everything succeeds with no errors.  InnoSetup should produce
  "success" messages very similar to the following:

  Successful compile (X.XXX sec). Resulting Setup program filename is:
  </li>
</ol>

<h3><a name="build.bat">build.bat Desription</a></h3>

<p>
  build.bat is the top level batch file for build automation and should be called
  with the configuration and platform to build:
  <ul>
    build.bat &lt;CONFIGURATION&gt; &lt;PLATFORM&gt;<br>
  </ul>
  This starts by setting 3 environment variables:
  <ul>
    ROOT (eg. &lt;pwd&gt;\..)<br>
    CONFIGURATION (eg. ReleaseNativeOnly)<br>
    PLATFORM (eg. Win32)<br>
  </ul>
  These are used to call another .bat file (eg. set_ReleaseNativeOnly_x64.bat)
  which calls set_ReleaseNativeOnly.bat to setup more variables to specify
  which .NET Framework to use:
  <ul>
    NETFX35ONLY=1 - set from set_ReleaseNativeOnly.bat<br>
    YEAR=2008 - set from set_ReleaseNativeOnly.bat<br>
    YEARS=%YEAR% - set from set_ReleaseNativeOnly.bat<br>
  </ul>
  build.bat attempts to set additional variables based on the chosen
  and available .NET Framework.
  <ul>
    YEAR (eg. 2008)<br>
    FRAMEWORKDIR (eg. %windir%\Microsoft.NET\Framework\v3.5)<br>
  </ul>
  The PATH variable is updated to include the directory specified by FRAMEWORKDIR.<br>
  At this point, several variables are setup for the call to 
  [http://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx | MSBuild]
  <ul>
    SOLUTION (eg. .\SQLite.NET.2008.sln)
    TARGET (eg. Rebuild)
    LOGGING
  </ul>
  MSBuild.exe is called to build the solution.
</p>