diff -r 97fd83492529 -r 3a3e4ca40b7c Tools__ProjectBuilderAssistantApplication.st --- a/Tools__ProjectBuilderAssistantApplication.st Sat Aug 13 12:40:32 2016 +0200 +++ b/Tools__ProjectBuilderAssistantApplication.st Mon Aug 22 11:26:34 2016 +0200 @@ -1,5 +1,3 @@ -"{ Encoding: utf8 }" - " COPYRIGHT (c) 2009 by eXept Software AG All Rights Reserved @@ -75,34 +73,34 @@ " Packager - A Standalone-Executable Builder and Packager - 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. + 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. Prerequisites * Windows Users: - Please install either the 'Borland Free Commandline Compiler Tools (bcc32)' - or the 'Microsoft Visual-C++' package (also free). + 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. - Due to limitations and bugs in the Visual-C++ compiler (limit on the size of - string-constants), some Smalltalk code is still not compilable - (currently, this affects 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 unable - 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 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). + Due to limitations and bugs in the Visual-C++ compiler (limit on the size of + string-constants), some Smalltalk code is still not compilable + (currently, this affects 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 unable + 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 recommend using the borland compiler suite. + Please install it at its standard location ('C:\Borland') as our makefiles might + still contain hard-coded paths (yes, we are ashamed about this). * Unix Users: - 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, + 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. Packages, Projects, PackageIDs and ProjectDefinitions @@ -110,59 +108,59 @@ Smalltalk basically uses two objects for packaging: * PackageIDs (also called ProjectID's occasionally) - * ProjectDefinitions - - 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 + * ProjectDefinitions + + 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). PackageIDs - These are simple symbols and are attached to classes and methods. If a method has + 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. - 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 + 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'. - 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' + 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. ProjectDefinitions - These describe the contents of a project, such as the classes to include, - the set of extension methods, any additional compilation information. + 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: * GUI Application Definition * non-GUI Application Definition - * ClassLibrary Definition - - 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). + * ClassLibrary Definition + + 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. Packaging - 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 + 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.). Structure of a Project @@ -170,41 +168,41 @@ The artefacts as manipulated by the packager are: * the ProjectDefinition class - 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), + 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. * the ApplicationModel class This defines the GUI, and is typically created using the UI-Painter. * the Startup class - 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. + 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. Build Procedure - All of the three components above can be generated by the packager to provide an + All of the three components above can be generated by the packager to provide an initial framework for further work. - 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, + 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. - 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 + 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 (the later with some limitations as explained above). - A self-installing executable is built using the NullSoft NSIS package. + A self-installing executable is built using the NullSoft NSIS package. This is also required to be installed before the packager is started. - 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 + 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. - Summary: It has NEVER been easier to create a GUI application with Smalltalk. + Summary: It has NEVER been easier to create a GUI application with Smalltalk. " ! !