From Bioinformatics.Org Wiki

[return to Winbirch]

---

Binaries/Winbirch-Bin-obsolete

Building Binaries Status Page

Contents 1 Binaries are developed using the BIRCHBINDEV account for WindowsXP on flamingo 2 Where do we get Source code or binaries? 3 Procedure for compiling 4 Integrating binaries into the bin and lib directories 5 Procedure for building the bin-xxx-xxx_D.tar.gz files

Binaries are developed using the BIRCHBINDEV account for WindowsXP on flamingo

For now, we are assuming that it is possible to just build binaries in 32-bit Windows XP, and hope they work on Windows7 and Windows8. All work therefore will be done by logging into flamingo.cs.umanitoba.ca:63389 as user BIRCHBINDEV.

In the Cygwin shell, the home directory is /home/BIRCHBINDEV. This corresponds to {fill in name of Windows directory}.

Where do we get Source code or binaries?

• FASTA3 bins
• PHYLIP bins
• NCBI
  • BLAST+ bins
  • sequinbins
  • cn3d bins codepage
• TCOFFEE bins home
• DIALIGN-TX binsrc
• Primer3 binssrc
• MrBayes binsrc
• XYLEM (Brian will provide source)
• FSAP (Brian will provide source)
• Acedb binsourcehome

Source code files are copied to the /home/BIRCHBINDEV/install, where each package has a separate directory. All compilation steps are done in that directory. It is best that each version of a program or package be in a separate directory. You can create a generic symbolic to point to the current one if there is more than one version. eg.

fasta3.5
fasta3.6
fasta --> fasta3.6

Procedure for compiling

It seem likely that this section should probably have its own page.

Dale, Graham, Maryam:

1. We need to get the Windows VMs set up with a complete set of tools necessary for compilation.

2. We need to test that binaries compiled using these tools run on various XP and Windows 7 machines without "dll hell" problems.

3. We need to maintain a set of instructions and guidelines on this page that will be the standard operating procedure.

Compilation will differ from package to package. For some packages, it will be enough to just run configure, followed by make. For some, there will be an already-existing makefile so you just run make. I can guarantee that some packages will require a tremendous amount of work to compile, which is part of why we try to avoid compiled programs in BIRCH.

Often, the directory for a package will have a local README file, telling whatever tricks were necessary to get a package to compile. I suppose we should probably keep this kind of information on the Wiki. To take that idea further, maybe each package (eg. FASTA, FSAP, Phylip) should have its own How to Build page with instructions on where to get source or binaries, and the various tricks or modifications to makefiles to get the code to compile. In some cases, not all of the compiled programs make it into a BIRCH distribution, so we probably need to have a list of which ones to include.

For all sources found in the birch-native-sources package, the procedure is as follows:

• Install mingw, and use the mingw bash shell for all operations.
• Run the command 'premake gmake' from within the desired source folder to generate the GNU-compliant make file. Premake binaries are found within the build_build package.
• Execute "make", and the sources are built.

This procedure is the same for all of the binaries, and works across all platforms (windows, osx, solaris, linux). For sources that are NOT within the birch-native-sources package, either follow the instructions for that particular package, or write a premake script for the package. In any case, MinGW will almost certainly be needed for any source compilation.

-Dale

Integrating binaries into the bin and lib directories

As binaries are successfully compiled, copy them into the appropriate bin directories:

bin-winxp-32 bin-win7-64

If there are DLL libraries, these should go to

lib-winxp-32 lib-win7-64

Note: Wherever possible, STATICALLY compile binaries, so that they have no dll dependencies. This prevents dependency and linkage problems, at the cost of slightly larger binaries.

This way, we slowly build up a complete set of binaries.

Think of these directories as something akin to the invariant of a loop. At any time, they contain the current versions of the binaries, and at any time, you can run the build/makebin.csh script and generate a new Development release of the binaries.

Procedure for building the bin-xxx-xxx_D.tar.gz files

/home/psgendb/BIRCHDEV/build has a script called makebin.csh. We will need to copy over the following files to BIRCHBINDEV/build:

makebin.csh makebin.exclude

This script is run from the build directory as follows:

./makebin.csh platform

where platform would be 'winxp-32' or 'win7-64' on Windows. This script creates a tar archive of all files directories in ../bin-winxp-32 and ../lib-winxp-32 or in ../bin-win7-64 and ../lib-win7-64, depending on the platform specified.

When BIRCHh is installed elsewhere, this .tar.gz file is untarred in the $BIRCH directory, so that the files automatically end up in the directories where they belong. Files listed in build/makebin.exclude are omitted from the .tar.gz file.

It is conceivable that makebin.csh will work under CygWin without change, but we have to try it and see.

This script should probably be re-written in Python.

The resultant files will be either bin-winxp-32_D.tar.gz or bin-win7-64_D.tar.gz. (These files contain both the bin AND lib directories).

The bin-xxx-xxx_D.tar.gz files are uploaded to the FTP/BIRCH/Development directory, where they are included in the Development release. When a stable release is generated, these bin files are copied to the directory for that release.