eXept Software AG Logo

Smalltalk/X Webserver

Documentation of class 'stx_libtool':

Home

Documentation
www.exept.de
Everywhere
for:
[back]

Class: stx_libtool


Inheritance:

   Object
   |
   +--ProjectDefinition
      |
      +--LibraryDefinition
         |
         +--stx_libtool

Package:
stx:libtool
Category:
* Projects & Packages *
Version:
rev: 1.185 date: 2019/07/31 20:48:43
user: cg
file: stx_libtool.st directory: libtool
module: stx stc-classLibrary: libtool
Author:
cg

Description:


Package documentation:

This library contains ST/X development tools, 
such as browsers for classes, files, changes, the debugger etc.

Some tools have been obsoleted by modernized replacement versions.
For example, the old FileBrowser, SystemBrowser and Inspector classes have
mostly been replaced by improved versions with better UI and more functionality.
These new versions are mostly found in libtool2.

Typically, these tools are not needed in end-user (standAlone) applications.    

Why keeping the old stuff?
Because some ST/X customers have based their own tools around and on top of some
older classes here, these will remain and will still be deployed in future versions.
However, for most, no active development is ongoing 
(i.e. the old SystemBrowser may not support new features, such as multiple programming languages, 
 refactorings, highlighting, breakpoints etc.
 although we keep them in a working state)


[primary maintainer:]
    cg


Class protocol:

accessing - hg
o  hgRemoveContainesForDeletedClasses
If true, then containers for removed classes are __AUTOMATICALLY__ removed from the
repositoru. If false, obsolete containes are kept.

Default is true (remove obsolete containers) but if the repository is mirror of CVS and
you want to merge back to CVS at some point, you may want to return false to avoid deletions
of obsolete files. Usefull when branching off an old CVS repo with loads of mess.

description
o  excludedFromPreRequisites
list all packages which should be ignored in the automatic
preRequisites scan. See #preRequisites for more.

o  mandatoryPreRequisites
list packages which are mandatory as a prerequisite.
This are packages containing superclasses of my classes and classes which
are extended by myself.
They are mandatory, because we need these packages as a prerequisite for loading and compiling.
When loading whole packages,
mandatoryPreRequisites will be automatically loaded
BEFORE this packet has been loaded.
This method is generated automatically,
by searching along the inheritance chain of all of my classes.
Please take a look at the #referencedPreRequisites method as well.

o  referencedPreRequisites
list packages which are a prerequisite, because they contain
classes which are referenced by my classes.
These packages are NOT needed as a prerequisite for compiling or loading,
however, a class from it may be referenced during execution and having it
unloaded then may lead to a runtime doesNotUnderstand error, unless the caller
includes explicit checks for the package being present.
When loading whole packages,
referencedPreRequisites will be automatically loaded
AFTER this packet has been loaded.
This method is generated automatically,
by searching all classes (and their packages) which are referenced by my classes.
Please also take a look at the #mandatoryPreRequisites method

o  subProjects
list packages which are known as subprojects.
The generated makefile will enter those and make there as well.
However: they are only built, not forced to be loaded when a package is loaded;
for those, redefine #referencedPrerequisites or #mandatoryPreRequisites.

description - compilation
o  additionalBaseAddressDefinition_bc_dot_mak
this is an optional definition, which (if present) may speed up the dll-loading a little
on win32 systems.

o  stcWarningOptions

description - contents
o  classNamesAndAttributes
lists the classes which are to be included in the project.
Each entry in the list may be: a single class-name (symbol),
or an array-literal consisting of class name and attributes.
Attributes are: #autoload or #<os> where os is one of win32, unix,...

o  extensionMethodNames
lists the extension methods which are to be included in the project.
Entries are 2-element array literals, consisting of class-name and selector.
A correponding method with real names must be present in my concrete subclasses
if it has extensions.

description - project information
o  companyName
Return a companyname which will appear in <lib>.rc

o  description
Return a description string which will appear in nt.def / bc.def

o  legalCopyright
Return a copyright string which will appear in <lib>.rc

o  productName
Return a product name which will appear in <lib>.rc

description - svn
o  svnRepositoryUrlString
Return a SVN repository URL of myself.
(Generated since 2011-04-08)
Do not make the string shorter!!! We have to use fixed-length keyword!!!

o  svnRevisionNr
Return a SVN revision number of myself.
This number is updated after a commit



ST/X 7.2.0.0; WebServer 1.670 at bd0aa1f87cdd.unknown:8081; Tue, 17 May 2022 20:28:58 GMT