NOTICE This chapter - although still valid to some degree - is now mostly obsoleted by the availability of the packager, which does all of the build process for you. You may skip this if you are not interested in the details and if you do not intent to build using a source code repository.
Don't be mislead by the name "projects" - your projects will NOT be stored there (for one: it is for exept-projects only; second: the name is a historic leftover).... stxXXX (where XXX is the ST/X release; currently 542) stx ... libbasic ... projects ... smalltalk ...
We are aware of the fact, that CVS is not the best choice, and will both provide support to deploy using other repositories (concrete: SVN or GIT). But for now, that's all we have and you have to live with it, just like we have to ;-)
Windows users will have to either download the free Borland 5.5 command-line tools or the Visual-C compiler or MINGW64 and install either (or all of them) at the default location.
For bcc, this is "c:\borland\bcc55". Make sure that bcc32 is found along your path by typing "bcc32" into
a command window.
Also notice, that there have to be two configuration files in the bin directory:
"C:\Borland\bcc55\Bin\bcc32.cfg" containing 2 lines:
Without them, bcc-compilations and linkage will fail later (the bcc-installer does not create those files!).
For MINGW, it is best to install it at its standard location or "C:\MINGW64".
Open a terminal window (xterm), and type both "cvs" and "gcc --version". There should be reasonable responses for both (aka: not "command not found").
Borland-C users should open a command window, and try both "cvs" and "bcc32" or "gcc". There should be reasonable responses for both.Sorry again, but now we are sure (too many people wrote emails in the past).
In case you use Visual-C, make sure that your shell environment includes the Visual-C path (VSINSTALLDIR). In a command window, type "echo %VSINSTALLDIR%". If that value is not set, look for a batch file named "%ProgramFiles%\Microsoft Visual Studio xx.0"\VC\bin\vcvars32.bat", and execute it (xx is one of "9.0", "10.0", "11.0" etc.). If required, add a call to that batch file to your "autoexec.bat".
Back in Smalltalk, open the "System"-"Settings" dialog in the launcher and navigate to the "Source Code Management"-settings.
:pserver:email@example.com:/cvs/stx" as CVSRoot-per-module for the "stx"-module.
The other setting (your own cvs repository as default) means that for all other classes, your local cvs server should be consultet.
Don't forget to check the "Use Local Source (suppress checkout)" flag in the CVS settings dialog. If you do forget it, your browser will access the exept CVS repository whenever it needs to show the source of a class or method. Although the fetched files will be cached (so the slow cvs-access is usually only performce once), but anyway this can be quite slow and annoying for quite some time, and is actually totally useless, because all files are already on your machine.
However, you should never ever modify those source files, if that "use local source"-flag is checked. If you do, the browser will show garbage, as it trusts the file to contain the method sources at exactly the position which has been compiled into the binary. That is: the binary only contains the file-offset position of the source from which it was compiled. Setting the "use local source"-flag tells the source code mangager, that it shall use those files and NOT ask the CVS repository. If you ever see garbage source code in the browser (after you accidentically modified your seources), uncheck that flag.
Right-click in the project-list, and select the "New..."-menu item.
Enter a reasonable package-ID for your own project (in the documentation you will also occasionally read "project-ID" - which is the same). A package-ID consists of two parts, separated by a colon: the module name and a repository path. The module component before the colon, MUST be the same as the name of your CVS-module. The stuff after the colon will be used as the directory path within the repository. As a rule of thumb, use package-IDs of the form
myOwnTopID : projectName / componentName (no spaces in-between)Notice that for deployed packages, every class and extension method with the same packageID will end up being compiled into the same dll. So if you have debug- and test-classes (unit tests), you'd better put them into a sub-package, such as: "myOwnTopID:projectName/componentName/test".
A concrete example would be:
Just to give you a rough idea. Use common sense and your experience.theBiggerBugLTD:salesApp/startup theBiggerBugLTD:salesApp/startup/tests theBiggerBugLTD:salesApp/gui theBiggerBugLTD:salesApp/gui/tests theBiggerBugLTD:salesApp/database/ theBiggerBugLTD:salesApp/database/support
If your application requires extension methods (that is: extensions to other classes),
these must be assigned to the corresponding package as well. For example, if you have
added a method for the
String class, which is required by your application,
move that to the appropriate package as well (there is a "Move"-"To Package..." also found
in the browser's method-list menu).
Don't forget the above step and don't try the stx project. If you do, the checkin operation below will try to check your classes into our exept repository. That will certainly fail, because what you reach there is a passive read-only copy of our real repository. Beside being read/only, it will also be overwritten when the next copy is made - typically the next night.
If you created the project as described above, you should already see those project definitons in the browser's project-tree. If not, it is now time to do it.
Then, have a look at the code as present so far (it is all found on the class-protocol side).
Some of these can be regenerated via class-lists menu items "Generate"-"Project Definition" and "Generate"-"Update Project Contents Definition" and also "Generate"-"Regenerate Project Contents Definition". (They differ on how they deal with existing code, and which definitons are regenerated. For now, only use the "Update" function, and edit the rest by hand.
Notice that the generated prerequisite list only includes packages of classes which are seen by a static code
analysis - if you construct class names dynamically, you should add the names of the corresponding
packages manually to the list.
If you update the list via the generator later, only new entries will be added.
If you "regenerate", you have to repeat your additions.
If the prerequisite generator adds packages for which you are absolutely sure that they are not needed (for example: testcases), add a method named "
excludedFromPreRequisites" and list those packages there.
If in doubt, use the browser and look at existing project-description classes as a guide - they are pretty easy to understand.
We usually define applications as a sub-project named "application",
and define all of the libraries as prerequisites.
You are not forced to do it like that - you can also put all of your classes into the application package,
and not use libraries at all. Or do a mix of both.
In any case, you will need a special startup class - that is the class which will play the role of the "main" function in a classic program. That's where the whole show starts later. Two major things must be specified: startup-className and startup-selector.
To have those files generated and also checked into the repository, select the "CheckIn Build-Support Files" from the project-lists menu (with the project selected, of course).
After the checkout or update, you should see the following directory hierarchy:
of course, the directory-names in the above example depend on how you named your projects in the above "Specifying the Project's Hierarchy" step.stxXXX (where XXX is the ST/X release; currently 542) theBiggerBugLTD salesApp startup gui ... stx ... libbasic
If you look at those directories in a filebrowser, explorer or K-Filelist, you should see all of your classes as ".st" files, makefiles, a resource file for windows-building, and a "bmake.bat" driver file. All of them have been generated and checked in by the "Generating Build Support Files" step above.
ormake (unix/linux systems)
orbmake (msdos systems with borland compiler)
That's it; the result should be an executable. For Win32 systems, if you have the nullsoft-install-system on your machine, a self-extracting install-exe is also created, which is ready for deployment. For Linux, an RPM packager is being developed and may be included in a future version (for now, simply tar/zip the build-directory, and unpack it on the target machine).vcmake (msdos systems with visual-C compiler)
or, for a Windows build:cd <yourTop>/<yourModule>/<yourDirectory> make
with stx installed under "cd <yourTop>\<yourModule>\<yourDirectory> bmake
to see how an application definition and a startup-class for standalone startup looks, load it and browse the code.clients/Demos/foxCalcApplication
Copyright © 1996 Claus Gittinger Development & Consulting
Copyright © eXept Software AG
<cg at exept.de>