--- 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.
"
! !