42 !

    43 

    44 help

    45 

    46 "/    Packager - A Standalone-Executable Builder and Packager

    47 "/    This assistant-application allows for standalone applications to be built very easily. It will generate all required classes, files, start the compilation process, generate a self-installable executable with a few mouse clicks. A simple demo application like the famous "Hello World" can be generated in a few minutes.

    48 "/    Prerequisites

    49 "/    Windows Users:

    50 "/    Please install either the "Borland Free Commandline Compiler Tools (bcc32)" or the "Microsoft Visual-C++" package (also free). In addition, the "NullSoft NSIS-Installer Package" is required.

    51 "/

    52 "/    Due to limitations and bugs in the Visual-C++ compiler (limit on the size of string-constants), some Smalltalk code is still not compilable (classes which contain image-resource methods for big images). Although microsoft is doing their best (a relative measure) to make things better (they increase the string-limit with every new release), they still seem to be undable to figure out how ti use malloc for string-data). We are patiently waiting for a real fix and still using bcc in the meanwhile. Therefore, we still recommend using the borland compiler suite. Please install it at its standard location ("C:\Borland") as our makefiles might still contain hard-coded pathes (yes, we are ashamed about this).

    53 "/    Unix Users:

    54 "/    You should already have the gcc compile suite (including all required header files) installed and ready to use. For a lack of time on our side, there is currently no self-installer support for Unix. The packager will generate a zipped tar file, which must be deployed and unpacked for use. This may change in the near future.

    55 "/    Packages, Projects, PackageIDs and ProjectDefinitions

    56 "/    Smalltalk basically uses two objects for packaging:

    57 "/

    58 "/        * PackageIDs (also called ProjectID's occasionally)

    59 "/        * ProjectDefinitions 

    60 "/

    61 "/    Older ST/X versions used instances of a Project class - this is now obsolete and removed from the system (although there are still some minor uses of it, which might remain there for backward compatibility for some time, as some customers have built their own packaging scheme around it).

    62 "/

    63 "/    PackageIDs

    64 "/    These are simple symbols and are attached to classes and methods. If a method has a packageID different from its class, it is called an extension method.

    65 "/    PackageIDs must have a certain fixed format: they always contain exactly two parts, which are separated by a colon character: the module and the directory part. The module is used as main-selector on where and how the source code repository is accessed. The directory is a path below that repository. If checked out into the local filesystem, the module defines the top-level directory. Thus, if a packageID is "stx:libbasic", the corresponding sources will be found in the repository associated to the "stx" module, under the directory "libbasic". In the local file system, it will be found under "stx/libbasic". As another example, if the packageID is "exept:expecco/plugins/foo", the repository is whichever is associated with the "exept" module, and the subdirectory is "expecco/plugins/foo". The local path to the sourcefiles would be "exept/expecco/plugins/foo".

    66 "/    Please notice that it does make sense to associate different repositories to different modules: for example, you could setup the sourceCodeManager to use CVS access to the exept repository for everything under the "stx" module, and at the same time, use a local SVN repository for everything under the "myCompany" module.

    67 "/    ProjectDefinitions

    68 "/    These describe the contents of a project, such as the classes to include, the set of extension methods, any additional compilation information. ProjectDefinitions come in 3 flavours:

    69 "/

    70 "/        * GUI Application Definition

    71 "/        * non-GUI Application Definition

    72 "/        * ClassLibrary Definition 

    73 "/

    74 "/    ProjectDefinitions are stored and managed as class-instances, located as subclasses of one of ApplicationDefinition or LibraryDefinition. As classes, they are themself managed, compiled and packaged as part of the project (and also have the same PackageID as their components). They are also treated like any other class w.r.t. source code management.

    75 "/    Packaging

    76 "/    All classes and extension methods belonging to a single package are supposed to be loaded (and possibly unloaded) together. They are also usually deployed inside a single dynamic link library ("dll", for short). In the Unix world, these are called "shared object" or "so". Finally, they are stored in a common directory both on the local file system and in a source code repository (CVS, SVN, etc.).

    77 "/    Structure of a Project

    78 "/    The artefacts as manipulated by the packager are:

    79 "/

    80 "/        * the ProjectDefinition class

    81 "/          This defines the type of application (GUI / non-GUI), its contents (i.e. the set of classes to be included in the binary itself and the set of library-dll's to be included in the deployed package), and some other metadata, such as icon, title etc.

    82 "/

    83 "/        * the ApplicationModel class

    84 "/          This defines the GUI, and is typically created using the UI-Painter.

    85 "/

    86 "/        * the Startup class

    87 "/          This is the first class which gets control when the executable is started; it can analyze the command line arguments, read patches or updates, start background ptocesses, and will eventually open the applications GUI. 

    88 "/

    89 "/    Build Procedure

    90 "/    All of the three components above can be generated by the packager to provide an initial framework for further work.

    91 "/

    92 "/    After the definition of those classes, all required files are stored in a temporary build directory. This means that the above classes are filed out, and make- and other support files are generated.

    93 "/

    94 "/    Finally, the actual build process is started. This requires an external C-compiler. Under windows, both Borland-C (free download available via the internet) and Microsoft's Visual-C++ (also available for free) can be used.

    95 "/

    96 "/    A self-installing executable is built using the NullSoft NSIS package. This is also required to be installed before the packager is started.

    97 "/

    98 "/    After the build, all required files are packaged in a single install-file. This is called "MyApplicationSetup.exe" and found in the project-specific subdirectory of the build directory. For deployment, this single file has to be delivered to a customer and executed there.

    99 "/

   100 "/    Summary: It has NEVER been easier to create a GUI application.