BIRCH/Meeting/Aug232012
From Bioinformatics.Org Wiki
[return to BIRCH Project/Meetings]
GOAL FOR TONIGHT: What I really want by the end of the evening is working BIRCHBINDEV directory, and a good start on whatever else is currently working on Windows.
Contents |
Quick walk through BIRCH Development Protocols and Directories (Brian)
- How do directories map between Linux, Cygwin and MingW?
- Is there a way to get winxp and win7 to share a working directory, or a user account, or does everything we do on winxp have to be duplicated on win7?
- Does it matter that binaries are compiled on MingW but our production platform is Cygwin?
- Are there things we need to do to ensure a smooth transition between Cygwin and Turtleshell?
Unix paths on Windows:
- cygwin
- Add /cygdrive/ to the windows path, and convert the \'s to /. Remove the :
- The home directory is ACTUALLY at /cygdrive/c/Documents\ and\ Settings/USERNAME on windows xp, and /cygdrive/c/Users/USERNAME on Windows Vista/7
- In cygwin, the path to the BIRCH folder is symlinked to /home/BIRCH, regardless of its physical location.
- Note: given any path, you can use the "cygpath" utility to convert it. For example, to get the windows form of a unix path, use cygpath -aw path.
- mingw
- Remove the :, convert all \'s to /.
Home directories:
- XP:
- C:\Documents and Settings\BIRCHBINDEV
- /cygdrive/c/Documents and Settings/BIRCHBINDEV (cygwin)
- Note: The actual $HOME directory inside of cygwin (type cd at the prompt) will be at C:\Documents and Settings\BIRCHBINDEV\BIRCHBINDEV\cygwin\home\BIRCHBINDEV on the windows filesystem.
- /c/Documents and Settings/BIRCHBINDEV (mingw)
- 7:
- C:\Users\BIRCHBINDEV
- /cygdrive/c/Users/BIRCHBINDEV
- Note: the actual $HOME directory inside of cygwin (type cd at the prompt) will be at C:\Users\BIRCHBINDEV\BIRCHBINDEV\cygwin\home\BIRCHBINDEV
- /c/Users/BIRCHBINDEV (mingw)
BIRCHBINDEV
Get this to the point where the BIRCHBINDEV/bin-winxp-32 directory has the current versions of all binaries so far.
- test - let's compile xylem
- premake - what is it, and is it really worth the extra overhead?
- Used to generate makefiles on each platform. If it is too much overhead, we can jsut do a single run-through to generate the makefiles, toss premake, and work off those. What you get with premake is GNU-compliant makefiles, that every make/gcc will like.
- BIRCHBINDEV/install - let's populate this directory with all of the working directories for the existing BIRCH binaries on Windows.
QUESTION - how realistic is it that these binaries will run on both winxp-32 and win7-64?
The next steps we'll do tonight, but in the near future, we need to test how good portable the binaries are on other Windows systems.
Dale - State of Getbrich installer on Windows
- Need a clear distinction between what Getbirch does and what install-scripts do.
- Getbirch now does the following:
- Grab the install-scripts for the specified version
- Grabs the framework and binaries for the specified version
- (windows only) grabs cygwin and required packages (our own archive), and installs that before running anything else
- Unarchives everything, placing install-scripts inside of the BIRCH folder
- Runs the install-scripts as a module, so that the output can be displayed on the getbirch console
- Getbirch now does the following:
- What is the current state of Getbirch and the install-scripts? In principle, if install-scripts were ready, we could work on them independently of Getbirch.
- The getbirch portion is currently done, the install-scripts are in development, and the major work being done is to convert the entire install process to python.
BIRCH install-scripts on Windows
The lack of a prototype install-scripts directory is holding up many aspects of BIRCH development.
- what things currently work?
- Right now, all the scripts that were already python
- what things still need work?
- The shell scripts need to be converted, and tested.
- Is there some way we could create a partial install-birch directory, and slowly move scripts over to it as they get completed?
- Yes
install-scripts should be platform agnostic (no special cases for windows)