-
Notifications
You must be signed in to change notification settings - Fork 0
Packaging Tinasoft
We strongly recommend to use Virtual Machines (eg. VMWare or VirtualBox) for packaging Tinasoft. This mean you must be able to access to Windows from Mac or Linux, or access Linux from Mac or Windows, to be able to build on every platform.
you must have cloned the GitHub project:
git clone git://github.com/moma/tinasoft.desktop.git
Under Linux, goes in the project root directory:
cd tinasoft.desktop
then type:
./build_unix
It should generate a .bz2 file
Packaging
Under MacOSX (real or virtual), goes in the project root directory:
cd tinasoft.desktop
then type:
./build_mac
It should generate a .zip file.
Notes
- The generated package should work on MacOSX 10.6 and 10.7
- People keep complaining about the application which can't be run in a .dmg. They don't understand that they must read the documentation, and know how a Mac work, before using the program. That's why DMG generation is currently disabled (commented in the build scripts)
First-step: Under Windows (real or virtual)
cd tinasoft.desktop\tinasoft\TinasoftPytextminer
then type:
python freeze_win.py build
Second-step: Under Linux/Mac (real or virtual) For the moment, the packaging script is released as a .sh script. To run it, you must go in the root directory:
cd tinasoft.desktop
then run the build script:
./build_win
This will generate a .zip file containing the package
Tinasoft Desktop use a simple approach to building: Bash (.sh) Scripts. This allow for nearly one-click (well, one or two commands) to package the whole app.
Things that are done:
- clean tmp, build, dist folders if necessary
- creating a stand-alone version of the app (that is, an executable!)
- packaging an embedded Python interpreter, for the right plateform
- freezing Python modules, with dependencies defined inside the setup.py, packaged inside a single site-packages.zip
- also packaging plateform-dependent Python libraries (.so, or .dll files)
- copying files necessary for the app: examples, licences, ngram datasets..
- also creating a bootstrap script, used to launch the app (the stand-alone executable is not enough)
- for Windows, copying the Microsoft framework necessary to run everything.
- Compressing everything into a single archive (.zip or .bz2 dependending on the target OS)
Things that are NOT done:
- downloading the git dependencies
- installing the Python libraries on the system (this is insanely complex on some systems like Mac or Windows)
- updating the latest version of the code via github (this is left to the package manager. Yes, you)
- testing the app (this is bad, but there are no automatic testing. You are warned)
- pushing to the FTP/SSH/HTTP server (also left to the package manager)
- AFTER packaging, cleaning the temporary folders used for building (so the dev can debug the build process!)
There are three different kind of scripts:
generic sub-scripts
these scripts are located in /devel/generic/
These scripts are shared by many plateforms (eg. copying text files, licences)
plateform-specific sub-scripts
These scripts are located in /devel/win/, /devel/mac/ and /devel/unix/
They do most of the job of compressing, copying, deleting files during the process. They are plateform specific (ie. on windows and mac, we use ZIP, on linux, BZ2. On windows, .EXE files)
top-level scripts
These are the three /build_win, /build_mac and /build_unix files located at the project root dir.
They define master variables like package name, package version, python version, architecture, which are passed in argument to the sub-scripts.
If you wish to update the version or the name, or the Python version, you should edit build_win, build_mac or build_unix with a code editor