eXept Software AG Logo

Smalltalk/X Webserver

Documentation of class 'ProjectDefinition':

Home

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

Class: ProjectDefinition


Inheritance:

   Object
   |
   +--ProjectDefinition
      |
      +--ApplicationDefinition
      |
      +--FolderForProjectsDefinition
      |
      +--LibraryDefinition

Package:
stx:libbasic
Category:
System-Support-Projects
Version:
rev: 1.750 date: 2024/04/22 16:50:47
user: stefan
file: ProjectDefinition.st directory: libbasic
module: stx stc-classLibrary: libbasic

Description:


As ST/X is (still) very tightly bound with stc, we keep the package and project information
in a class-object (instead of some project object) and all queries about package contents and
attributes are implemented as class methods.
(after all: a class is an object, which can be asked by sending it messages...
 ... so why would one want extra meta-descriptions with extra syntax?)

This has the advantage, that it can be compiled and included in a compiled class library just like any other class.

Every package includes a subclass of me (an instance of my meta), which provides useful
information about the versioning and packaging.
Me myself, I know how to generate dependency information and can generate makefiles and other build-support
files for compilation (see the browser's 'Checkin Build Support File' menu item. For more details, see
section 'Build Support Files' below).

When a package is loaded from a binary shared class lib (i.e. a compiled class library is loaded
via 'Smalltalk loadPackage:'), the loading is done in multiple phases:
    1) the shared object is loaded, but not installed (registered) in Smalltalk
    2) the ProjectDefinition class is registered and initialized.
    3) the ProjectDefinition class is asked to load its prerequisites.
       This may recursively lead to other packages to be loaded
       - either as binary class libraries, as bytecode or from source; whichever is found.
    4) the remaining classes and extensions of the package are registered

## Some special notes about extension methods:
  if a package is loaded (Smalltalk loadPackage:'foo:bar/baz'), any already loaded package of which
  methods are overwritten by an extension method of the loaded package, the other package is asked to safe those
  methods in its safe(ForOverwrittenMethods).
  Thus, if the other package or any of its classes is asked
  to file itself out, it can do so using the safe (otherwise, you'd not be able to check the original class into
  its repository while it has an overriding extension loaded).

  Also, the information about which other package was in charge when a method is overwritten is recorded in
  extensionOverwriteInfo.
  This is used to correctly reinstall any overwritten method, whenever a package is unloaded.

## Build Support Files

To support compilation of a package, ProjectDefinition can generate a set of makefiles and other
support files to allow that. To see the set of files that should be generated, see #fileNamesToGenerate.
These files are usually generated and saved to the repository upon a commit - the source code management
does (should) care for this.

Packages may add more files to this list by defining an (extension) method in project definition class
and by annotating the method by <file:overwrite:> annotation:

    * the first parameter is the file name to generate as String, relative to the package root. As directory
      separator, use slash (as on UNIX), it will be automagically converted to platform's separator.
    * The second parametrer (true or false) tells the SCM whether the file should be generated (and thus
      overwritten) upon each commit (when true) or only the first time (when false). Important: see the
      remark below.
    * The method itself should return file's contents a string. If it returns nil, then the file is *not*
      generated at all.

For examples, see #generate_java_build_auto_dot_xml and #generate_java_build_dot_xml defined by STX:LIBJAVA.

REMARK: CAUTION:
The overwrite: boolean is currently *not* supported by old SCM managers, more specifically
CVSSourceCodeManager does not support it. CVSSourceCodeManager will always overwrite the file!
It *is* supported by all SCMs based on new stx:libscm. More specifically, *it is supported* by
Mercurial.

## Adding additional rules to generated makefiles

There are two ways to add additional rules to generated makefiles (Make.proto and bc.mak):
  1) overriding #additionalRules_make_dot_proto and/or #additionalRules_bc_dot_mak
  2) adding a method annotated by <file:target:> or <file:target:extends:>

### Overriding #additionalRules* methods

You may override #additionalRules_make_dot_proto and/or #additionalRules_bc_dot_mak and return
string containing the code of the rules. This string is inserted to the resulting makefile
as-is. This is the traditional way of doing this.

If you any of the targets defined there to be called as part of standard build, you may
also want to list these targets in #additionalTargets_make_dot_proto and/or
#additionalTargets_bc_dot_mak

### Adding annotatated method

Alternatively, you may add one method per rule and annotate it by
<file:target:> or <file:target:extends:> annotation. For example,
to call 'ant' whenever a package is built, add a method like:

additionalRuleAnt_make_dot_proto
    <file: 'Make.proto' target: 'ant' extends: 'pre_objs' >

    ^ '
    java:
            ant -f java/build.xml
    '

The meaning annotation parameters is the following:

    * file: <String> - name of the file in which to include
      the rule. Currently only two values are valid:
      'Make.proto' and 'bc.mak'.
    * target: <String> - name of the target'
    * extends: <String> - optional name of the target that this additional
      rule extends. This means that the extending target (specified by target:
      annotation parameter) is called as part of building of  the extended target
      (i.e., the target specified by extends: annotation parameter). Not all targets
      are extendible, see below.

Method annotated by these annotations should return - when executed - a string
with exactly one rule. The rule name SHOULD match with the name in target: annotation
parameter, otherwise the extends: parameter will not work correctly.
If the methor returns nil, the rule is not included in resulting makefile.

The advantage of this approach is that it allows for additional, non-basic packages to hook in
and add their own targets if they want to. The disadvantage is that if package makefiles
are regenerated without this extending package loaded, targets are lost. To avid this,
you may want to add this non-basic package to prerequsites.

Currently, this mechanism is used by STX:LIBJAVA to call ant to compile package's java classes.

#### Extendable targets

Make.proto:
    all
    clean
    ...more to be added...

bc.mak
    ALL
    clean
    ...more to be added...

copyright

COPYRIGHT (c) 2006 by eXept Software AG All Rights Reserved This software is furnished under a license and may be used only in accordance with the terms of that license and with the inclusion of the above copyright notice. This software may not be provided or otherwise made available to, or used by, any other person. No title to or ownership of the software is hereby transferred.

buildingMakefiles

You can define additional rules and flag settings for use in the makeFile generation: redefinable build-file attributes: stcOptimizationOptions -> STCLOCALOPT stcWarningOptions -> STCLOCALOPT localIncludes_unix -> LOCALINCLUDES (Make.proto) localIncludes_win32 -> LOCALINCLUDES (bc.mak) for applications: startupClassName startupSelector for libraries:

Class protocol:

accessing
o  additionalClassResources

o  directory
for packageId compatibility

o  extensionsRevisionInfoForManager: managerOrNil
return the revisionInfo object for my extensions for a particular source code manager.
Return nil, if there is either no manager, or I have no extensions

Usage example(s):

     (stx_libcomp extensionsRevisionInfoForManager:nil) revision
     (stx_libbasic extensionsRevisionInfoForManager:nil)

o  fullPackageName
all components with underlines

Usage example(s):

     stx_libwidg2 packageName
     stx_libwidg2 fullPackageName
     stx_goodies_refactoryBrowser_browser packageName
     stx_goodies_refactoryBrowser_browser fullPackageName

o  fullPackageNameFor: aProjectID
stx_goodies_refactoryBrowser_lint fullPackageNameFor:#stx_goodies_refactoryBrowser_lint

o  initialClassNameForDefinitionOf: aPackageId
now obsolete - left here for backward compatibility
given a package-ID, return an appropriate class name for this package

** This is an obsolete interface - do not use it (it may vanish in future versions) **

o  libraryName
bosch_dapasx_datenbasis libraryName
stx_libbasic3 libraryName

o  libraryNameFor: aProjectID
bosch_dapasx_datenbasis libraryName
stx_libbasic3 libraryNameFor:'stx:libbasic'
stx_libbasic3 libraryNameFor:'bosch:dapasx/datenbasis'

o  loadDirectory
if I was loaded from a directory (as opposed to loaded via a dll or from a source code manager),
return that directory. Otherwise return nil.

o  loadDirectory: aDirectory
remember the directory from which I was loaded from

o  module
bosch_dapasx_datenbasis_Definition module
DapasX_Datenbasis module
stx_libbasic3 module
stx_libbasic3 directory

o  moduleDirectory
bosch_dapasx_datenbasis_Definition moduleDirectory
bosch_dapasx_parameter_system_Definition moduleDirectory
stx_libbasic3 moduleDirectory
cg_croquet moduleDirectory
cg_croquet package asPackageId module
cg_croquet moduleDirectory
stx_goodies_xml_vw moduleDirectory
cg_demos_demo1 moduleDirectory

o  moduleDirectoryFor: aProjectID
everything after the colon

o  moduleDirectory_win32
bosch_dapasx_datenbasis moduleDirectory_win32
bosch_dapasx_parameter_system moduleDirectory_win32
stx_libbasic3 moduleDirectory_win32

o  moduleDirectory_win32For: projectID
self moduleDirectory_win32For: #'bosch:dapasx/pav_vergleich'
self moduleDirectory_win32For: #'stx:goodies/xml/stx'
self moduleDirectory_win32For: #'stx:libbasic2'

o  moduleFor: aProjectID
DapasXProject module
DapasX_Datenbasis module

o  moduleOfClass: aClass
DapasXProject module
DapasX_Datenbasis module

o  monticelloPackageName
hook for packages which have been loaded from monticello

o  msdosPathToPackage: toPackageID from: fromPackageID
Returns the path to the package defined by aPackageID relative to my path

Usage example(s):

     self msdosPathToPackage:'bosch:dapasx/kernel' from:'bosch:dapasx/application'
     self msdosPathToPackage:'stx:libbasic' from:'bosch:dapasx/application'
     self msdosPathToPackage:'bosch:dapasx/application' from:'stx:libbasic'
     self msdosPathToPackage:'exept:expecco' from:'exept:expecco/application'
     self msdosPathToPackage:'exept:expecco/application' from:'exept:expecco'

o  packageDirectory
if I was loaded from a directory (as opposed to loaded via a dll or from a source code manager),
return that directory.
Otherwise ask Smalltalk for my package directory a long the package path.
For standalone apps, nil might be returned if the package's folder is not part
of the deployed package.

o  packageName
the last component

Usage example(s):

     stx_libwidg2 packageName
     stx_goodies_refactoryBrowser_browser packageName
     bosch_dapasx_hw_schnittstellen packageName
     bosch_dapasx_datenbasis packageName
     bosch_dapasx_parameter_system packageName

o  packageNameFor: aProjectID
bosch_dapasx_hw_schnittstellen packageName
bosch_dapasx_datenbasis packageName
bosch_dapasx_parameter_system packageName
cg_croquet packageName
stx_goodies_xml_vw packageName
stx_goodies_xml_vw packageDirectory

o  parentProject
return the packageID of the parent project.
That is the projectID of the package above in the folder hierarchy

Usage example(s):

     bosch_dapasx_hw_schnittstellen_Definition parentProject
     DapasX_Datenbasis parentProject

     stx_libbasic parentProject
     stx_goodies_refactoryBrowser_lint parentProject

o  parentProjectFor: aProjectID
given a packageID symbol or string, return the packageID of the
parent project.
That is the projectID of the package above in the folder hierarchy

Usage example(s):

     bosch_dapasx_hw_schnittstellen parentProject

     self parentProjectFor:'bosch:dapasx'
     self parentProjectFor:'bosch:dapasx/hw_schnittstellen'
     self parentProjectFor:'stx:goodies/refactoryBrowser/lint'
     self parentProjectFor:'stx:goodies/svg'
     self parentProjectFor:'stx:libbasic'
     self parentProjectFor:'exept:expecco/application'

     self parentProjectFor:'stx'
     self parentProjectFor:'exept'

o  pathSeparator: platformName

o  pathTo: aBaseFilename inPackage: aPackageID architecture: arch
Returns the path to stx counting the number of $/ and $: in the package name and adding for each one '../' to get the ST/X top directory

o  pathToPackage: toPackageID from: fromPackageID withSeparator: pathSeparator
Returns the path to the package defined by aPackageID relative to my path

Usage example(s):

     self pathToPackage:'bosch:dapasx/kernel' from:'bosch:dapasx/application' withSeparator:'\'
     self pathToPackage:'stx:libbasic' from:'bosch:dapasx/application' withSeparator:'\'
     self pathToPackage:'bosch:dapasx/application' from:'stx:libbasic' withSeparator:'\'
     exept_expecco_application pathToPackage:'exept:expecco' from:'exept:expecco/application' withSeparator:'/'
     exept_expecco_application pathToPackage:'exept:expecco/plugins/guiBrowser' from:'exept:expecco/application' withSeparator:'/'

o  pathToPackage: aPackageID withSeparator: pathSeparator
Returns the path to stx counting the number of $/ and $: in the package name and adding for each one '../' to get the ST/X top directory

Usage example(s):

     exept_expecco_application pathToPackage:'exept:expecco/application' withSeparator:'\'
     exept_expecco_application pathToPackage:'exept:expecco/report' withSeparator:'\'
     exept_expecco_application make_dot_proto_resource_rules
     stx_libbasic pathToPackage:'exept:expecco/application' withSeparator:'\'

o  pathToTopFor: aProjectID withSeparator: aPathSeparator
Returns the path to stx counting the number of $/ and $: in the package name and adding for each one '../' to get the ST/X top directory

Usage example(s):

     self pathToTopFor: #'exept' with:'/'
     self pathToTopFor: #'exept:expecco' with:'/'
     self pathToTopFor: #'exept:expecco/application' with:'/'
     self pathToTopFor: #'stx' with:'/'
     self pathToTopFor: #'stx:libview' with:'/'
     self pathToTopFor: #'stx:goodies/foo' with:'/'

o  pathToTopWithSeparator: aPathSeparator
Returns the path to stx counting the number of $/ and $: in the package name and adding for each one '../' to get the ST/X top directory

Usage example(s):

     exept_expecco_application pathToTopWithSeparator:'\'
     stx_libbasic pathToTopWithSeparator:'\'
     stx_goodies_xml pathToTopWithSeparator:'\'
     stx_libhtml pathToTopWithSeparator:'\'
     stx_goodies_refactoryBrowser_changes pathToTopWithSeparator:'\'

o  projectDefinitionClassNameForDefinitionOf: aPackageId
given a package-ID, return an appropriate class name for this package

o  projectIsLoaded
answer true, if this project is completely loaded into the image

Usage example(s):

      stx_libbasic projectIsLoaded
      (ProjectDefinition definitionClassForPackage:#'stx:libbasic') projectIsLoaded

o  projectIsLoaded: aBoolean
register myself as dependent - I want to get notified on method changes

o  projectTags
a list of resource-tags used in the project.
These are offered in the browser's methodList menu as 'Tag as' items.
Allowing convenient tagging for things like '<resource: EXPECCO_API>'.
When redefined, a collection of useful tag-strings should be returned.

o  topRelativePathTo: aBaseFilename inPackage: aPackageID architecture: arch
Returns the path to stx counting the number of $/ and $: in the package name
and adding for each one '../' to get the ST/X top directory

o  topRelativePathToPackage: aPackageID withSeparator: aDirectorySeparator
Returns the path to the package as specified by aPackageID relative to the top directory.
Basically this simply replaces colons and slashes by the OS's path separator.

Usage example(s):

     self topRelativePathToPackage:'stx:goodies/xml' withSeparator:'\'
     self topRelativePathToPackage:'bosch:dapasx/kernel' withSeparator:'\'

accessing - coverage
o  excludedFromCoverage
List of classes and/or methods excluded from coverage report.
Entries maybe ClassName or #(ClassName selector)

Please note that certain classes and methods are excluded
in #Builder::CoverageReport>>excludedFromCoverage:.

o  excludedFromCoverage: aMethod
Return true if given method should be excluded from coverage
info. This method may be redefined in subclasses to automagically omit methods
matching some criteria.

Please note that certain classes and methods are excluded
in Builder::CoverageReport>>excludedFromCoverage:.

accessing - packaging
o  classNames: aCollectionOfClassNames
set the set of classes

o  classNamesAndAttributes: newSpec usingCompiler: compilerOrNil
set the set of classes. and attributes
Because this requires compilation of my classList-method, a compiler can be passed in,
which has to do the job.
(this is used by the systembrowser to pass in a CodeGeneratorTool with undo support)

o  excludeClasses: toExclude usingCompiler: compilerOrNil
exclude (remove from classList) a number of classes.
Because this requires compilation of my classList-method, a compiler can be passed in,
which has to do the job.
(this is used by the systembrowser to pass in a CodeGeneratorTool with undo support)

o  excludeMethodFor: selector inClassNamed: className usingCompiler: compilerOrNil
exclude (remove from extensionList) a method by name.
Because this requires compilation of my extensionMethodNames-method, a compiler can be passed in,
which has to do the job.
This is used by the systembrowser to pass in a CodeGeneratorTool with undo support.
If nil is passed in, the recurlar compiler is used (no undo support)

o  excludeMethods: toRemove usingCompiler: compilerOrNil
exclude (remove from extensionList) a number of methods.
Because this requires compilation of my extensionMethodNames-method, a compiler can be passed in,
which has to do the job.
This is used by the systembrowser to pass in a CodeGeneratorTool with undo support.
If nil is passed in, the recurlar compiler is used (no undo support)

o  includeClasses: toInclude usingCompiler: compilerOrNil
include (add to classList) a number of classes.
Because this requires compilation of my classList-method, a compiler can be passed in,
which has to do the job.
This is used by the systembrowser to pass in a CodeGeneratorTool with undo support.
If nil is passed in, the recurlar compiler is used (no undo support)

o  includeMethods: toInclude usingCompiler: compilerOrNil
include (add to extensionList) a number of methods.
Because this requires compilation of my extensionMethodNames-method, a compiler can be passed in,
which has to do the job.
This is used by the systembrowser to pass in a CodeGeneratorTool with undo support.
If nil is passed in, the recurlar compiler is used (no undo support)

o  makeClassesAutoloaded: toMakeAutoloaded usingCompiler: compilerOrNil
include as autoloaded (add to classList) a number of classes.
Because this requires compilation of my classList-method, a compiler can be passed in,
which has to do the job.
(this is used by the systembrowser to pass in a CodeGeneratorTool with undo support)

o  updateContentsMethodsCodeUsingCompiler: compilerOrNil ignoreOldDefinition: doRegenerate
regenerate the contents-describing methods.
This searches through the system and picks classes and extension methods
which have me as package and lists them in the generated class-
and extensionMethods methods.
If doRegenerate is true, forget any any previous contents info;
otherwise, merge new items into the existing lists.

o  updateExtensionMethodNamesUsingCompiler: compilerOrNil
set the set of extension methods
Because this requires compilation of my extensionMethodNames-method,
a compiler can be passed in, which has to do the job.
(this is used by the systembrowser to pass in a CodeGeneratorTool with undo support)

o  updateMethodsCodeUsingCompiler: compilerOrNil ignoreOldDefinition: doRegenerate
regenerate the all contents- plus version describing methods.
This searches through the system and picks classes and extension methods
which have me as package and lists them in the generated class-
and extensionMethods methods.
If doRegenerate is true, forget any any previous contents info;
otherwise, merge new items into the existing lists.

accessing - tests
o  excludedFromTestSuite
List of testcases and/or tests excluded from testsuite.
Entries maybe ClassName or #(ClassName testName)

o  testSuite
generate and return a testSuite containing all of my test-classes

class initialization
o  initialize
self initialize

o  initializeAllProjectDefinitions
tells all already loaded project definition classes that they are loaded
(i.e. calls postLoadAction).
This needs everything else (especially the compiler etc.) to be initialized.
Therefore, it's not invoked by the projDef's #initialize,
but instead explicitely, by Smalltalk as a late step in the startup.

o  installAutoloadedClasses
install all of my autoloaded classes (if any)

Usage example(s):

     stx_libbasic installAutoloadedClasses
     stx_libhtml installAutoloadedClasses
     stx_libtool2 installAutoloadedClasses

code generation
o  applicationIconFileNameLinux_code
self applicationIconFileNameLinux_code
stx_libbasic3 applicationIconFileNameLinux_code

o  applicationIconFileNameOSX_code
self applicationIconFileNameOSX_code
stx_libbasic3 applicationIconFileNameOSX_code

o  applicationIconFileNameWindows_code
self applicationIconFileNameWindows_code
stx_libbasic3 applicationIconFileNameWindows_code

o  applicationIconFileName_code
obsolete - replaced by three separate methods as-per-OS

Usage example(s):

     self applicationIconFileName_code
     stx_libbasic3 applicationIconFileName_code

o  checkForBadReferences: prerequisiteList
check, that there are no 'illegal' references to prerequisites.
If there is a bad prequisite, ask the user whether to abort.

o  classNamesAndAttributes_codeFor: aSpecArray
generate method code returning all classes of the project from the given spec.

Usage example(s):

     stx_libbasic3 classNamesAndAttributes_codeFor:(stx_libbasic3 classNamesAndAttributes)
     exept_expecco classNamesAndAttributes_codeFor:(exept_expecco classNamesAndAttributes)

o  classNamesAndAttributes_code_ignoreOldEntries: ignoreOldEntries ignoreOldDefinition: ignoreOldDefinition
generate method code returning all classes of the project.
Platform attributes are kept from the old definition.
If ignoreOldEntries is true, the list is completely recreated;
if false, existing entries are preserved.
If ignoreOldDefinition is true, the autoload attribute is set/reset if
the class is installed as autoloaded in the image (i.e. the state in the image is taken).
If false, it is taken from an existing definition in #classNamesAndAttributes

Usage example(s):

     stx_libbasic3 classNamesAndAttributes_code_ignoreOldEntries:false ignoreOldDefinition:true
     exept_expecco classNamesAndAttributes_code_ignoreOldEntries:false ignoreOldDefinition:true

o  companyName_code
generate code that answers the company name.

Usage example(s):

     self companyName_code
     stx_libbasic3 companyName_code

o  companyName_codeFor: aString
generate code that answers aString as the company name.

o  compileDescriptionMethods
self instAndClassMethodsDo:[:m | m package:self package].

Usage example(s):

     DapasXProject compileDescriptionMethods
     DapasX_Datenbasis compileDescriptionMethods
     bosch_dapasx_interactiver_editor compileDescriptionMethods
     stx_libbasic compileDescriptionMethods

o  description_code
self description_code
stx_libbasic3 description_code

o  effectiveSubProjects
get the subProjects for the current OS platform, that are not excluded

o  effectiveSubProjects: osSymbol
get the subProjects, that are not excluded explicitely
or built anyway as (mandatory) prerequisite.
osSymbol can be #win32 or #unix (for now).

o  effectiveSubProjectsForBuildFile: osSymbol
get the subProjects, that are not excluded explicitely
or built anyway as (mandatory or referenced) prerequisite.
osSymbol can be #win32 or #unix (for now).

o  excludedFromPreRequisites_code
generate the code of the #excludedFromPreRequisites method

o  extensionMethodNames_code
self extensionMethodNames_code

o  extensionMethodNames_code_For: extensionMethodNames

o  extensionMethodNames_code_ignoreOldEntries: ignoreOldEntries
JV@2012-09-07: Do not list Java methods in extensionMethodNames.
They are loaded lazily by JavaClassReader and if listed here,
they would cause an error if the package is loaded from source.
Sort of a HACK, indeed

Usage example(s):

     self extensionMethodNames_code_ignoreOldEntries:false
     stx_libjava extensionMethodNames_code_ignoreOldEntries:false
     stx_libtool extensionMethodNames_code_ignoreOldEntries:true

o  forEachContentsMethodsCodeToCompileDo: aTwoArgBlock ignoreOldDefinition: ignoreOldDefinition
generate code for each contents-specifying method
(classesAndAttributes, extensionMethodNames, etc.),
and evaluate aTwoArgBlock on it, passing in the code and the method's category.
If ignoreOldDefinition is true, new code is generated (class/method scan);
otherwise, new items are added to the existing lists

o  forEachDescriptionMethodsCodeToCompileDo: aTwoArgBlock ignoreOldDefinition: ignoreOldDefinition
generate code for descriptive methods,
and evaluate aTwoArgBlock on it, passing in the code and the method's category.
If ignoreOldDefinition is true, new code is generated (class/method scan);
otherwise, new items are added to the existing lists

o  forEachMethodsCodeToCompileDo: aTwoArgBlock
update code for each method (contents plus version info),
and evaluate aTwoArgBlock on it, passing in the code and the method's category.
New items are added to the existing lists

o  forEachMethodsCodeToCompileDo: aTwoArgBlock ignoreOldDefinition: ignoreOldDefinition
generate code for each method (contents plus version info),
and evaluate aTwoArgBlock on it, passing in the code and the method's category.
If ignoreOldDefinition is true, new code is generated (class/method scan);
otherwise, new items are added to the existing lists

o  legalCopyright_code
self legalCopyright_code
stx_libbasic3 legalCopyright_code

o  mandatoryPreRequisites_code
generate the code of the #mandatoryPreRequisites method

Usage example(s):

     demo_demoApp1 mandatoryPreRequisites_code
     stx_libbasic3 mandatoryPreRequisites_code
     stx_libtool2 mandatoryPreRequisites_code

o  productInstallDirBaseName_code
ApplicationDefinition productInstallDirBaseName_code
stx_libbasic3 productInstallDirBaseName_code
stx_clients_Clock_QlockTwoWatchApplication productInstallDirBaseName_code

o  productName_code
generate code that answers the product name.

Usage example(s):

     self productName_code
     stx_libbasic3 productName_code

o  productName_codeFor: aString
generate code that answers aString as the product name.

o  referencedPreRequisites_code
generate the code of the #referencedPreRequisites method

Usage example(s):

     demo_demoApp1 referencedPreRequisites_code
     stx_libbasic3 referencedPreRequisites_code
     stx_libtool2 referencedPreRequisites_code

o  subProjects_code
generate the code of the #subProjects method.
Returns nil if no such code is needed (because there are none)

o  svnRevisionNr_code: revisionNrOrNil
self svnRevisionNr_code
stx_libbasic3 svnRevisionNr_code

defaults
o  applicationTypes
self applicationTypes

o  defaultCategory

o  defaultProjectType
^ self applicationTypes first

o  defaultProjectTypeForGUIApplication

o  defaultProjectTypeForNonGUIApplication

o  folderForSubApplicationsType

o  guiApplicationType

o  libraryType

o  libraryTypes
self libraryTypes

o  nonGuiApplicationType

o  projectTypeSelectors
a list of possible project type selectors

o  projectTypes
a list of possible project types (shown in the new-package dialog's combo list)

Usage example(s):

     self projectTypes

description
o  excludedFromMandatoryPreRequisites
list packages which are to be explicitely excluded from the automatic constructed
mandatory prerequisites list.
If empty, everything that is found along the inheritance of any of
my classes is considered to be a prerequisite package.

o  excludedFromPreRequisites
obsolete; temporarily, this is still called for, but will eventually vanish.

List packages which are to be explicitely excluded from the automatic constructed
prerequisites lists (both).
If empty, everything that is found along the inheritance of any of
my classes is considered to be a prerequisite package.

o  excludedFromRequiredPreRequisites
list packages which are to be explicitely excluded from the automatic constructed
required prerequisites list.
If empty, everything that is found along the inheritance of any of
my classes is considered to be a prerequisite package.

o  excludedFromSubProjects
list packages which are to be explicitely excluded from the automatic constructed
subProjects list. If empty, every sub-package is included as a prerequisite.

o  includedInPreRequisites
list packages which are to be implicitely included in the prerequisites list,
even if not found by the automatic search.
Redefine this, if classes from other packages are referred to via reflection
or by constructing names dynamically (i.e. the search cannot find it)

o  includedInSubProjects
list packages which are to be explicitely included in the subproject list,
even if not found by the automatic search.
However: they are not forced to be loaded when a package is loaded;
for those, redefine #includedInPreRequisites.

o  is: aPackageName excludedFrom: aListOfExcludedPatterns
common helper to check if a package is excluded from an exclusion list.
The list used to be a simple collection of package names previously,
but is now a list of names or GLOB match patterns

o  isExcludedFromMandatoryPreRequisites: aPackageName

o  isExcludedFromPreRequisites: aPackageName

o  isExcludedFromRequiredPreRequisites: aPackageName

o  isExcludedFromSubProjects: aPackageName

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  nonMandatorySubProjects
list subprojects which can be ignored if the folder has been removed.
Make will give a warning, but proceed.
Should be a subset of what is returned by #subProjects

o  preRequisites
list packages which are required as a prerequisite (both mandatory and referenced).
This is used to build dependency chains in makefiles

o  preRequisitesFor: packageId
Maybe the package is not loaded? Try to load it...

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  siblingsAreSubProjects

o  splashFileName
answer the base-name of the splash bitmap.

Default is nil, for no splash. If non-nil, it must be a bmp file's name

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.

o  superProject
return the package which contains me as subProject,
or if not found, which contains me under its directory hierarchy,
or nil if none found

Usage example(s):

     stx_goodies_refactoryBrowser_lint superProject
     exept_expecco_plugin_guiBrowser superProject

description - actions
o  postLoadAction
invoked after loading a project

o  preLoadAction
invoked before loading a project

o  preUnloadAction
invoked before unloading a project

description - compilation
o  additionalBaseAddressDefinition_bc_dot_mak
allows for a base-address definition to be added to the bc.mak file.
Subclasses may redefine this to something like
LIB_BASE=$(LIBWIDG_BASE)
This will be inserted BEFORE the 'include stdHeader'

o  additionalDefinitions
allows for additional definitions/rules to be added to both the Make.proto and bc.mak file.

o  additionalDefinitions_bc_dot_mak
allows for additional definitions/rules to be added to the bc.mak file.
Subclasses may redefine this.

o  additionalDefinitions_make_dot_proto
allows for additional definitions/rules to be added to the make.proto file.

o  additionalDefinitions_nt_dot_mak
obsolete - kept for compatibility with old project files

o  additionalHeaderRulesUsingTemplate: template withSeparator: pathSeparator
rules for header files (of autoloaded classes).
For each extended class, which is autoloaded (and therefore, we will not find a header file for it),
generate a rule to create the header file only.

o  additionalHeaderRules_bc_dot_mak
rules for header files (of autoloaded classes)

o  additionalHeaderRules_make_dot_proto
rules for header files (of autoloaded classes)

o  additionalLinkLibraries_bc_dot_mak
allows for additional static libraries to be added to the bc.mak file.
Subclasses may redefine this

o  additionalLinkLibraries_make_dot_proto
allows for additional static libraries to be added to the make.proto file.

o  additionalLinkLibraries_nt_dot_mak
obsolete - kept for compatibility with old project files

o  additionalRulesFor: fileToGenerateFor
Return additional rules for given file specified by <rule:file:> or <rule:extends:file:>.

See class documentation on rule extension methods

Usage example(s):

    stx_libjava additionalRulesFor: 'Make.proto'
    stx_libjava additionalRulesFor: 'bc.mak'

    stx_libjava generateFile:'Make.proto'
    stx_libjava generateFile:'bc.mak'

o  additionalRulesHG_bc_dot_mak
stx_libscm_mercurial additionalRulesHG_bc_dot_mak

o  additionalRulesHG_make_dot_proto
stx_libscm_mercurial additionalRulesHG_make_dot_proto

o  additionalRulesSvn_make_dot_proto
stx_libbasic3 additionalRulesSvn_make_dot_proto

o  additionalRules_bc_dot_mak
obsolete - kept for compatibility with old project files

o  additionalRules_make_dot_proto
allows for additional rules to be added to the make.proto file.

o  additionalSharedLinkLibraries_make_dot_proto
allows for additional shared libraries to be added to the make.proto file.

o  additionalTargetsSvn_make_dot_proto
Returns additional targets to make when build projec
checked out from SVN

o  additionalTargets_bc_dot_mak
can list additional bc.mak targets (additional windows support files)

o  additionalTargets_make_dot_proto
can list additional Make.proto targets (additional unix support files)

o  additional_post_nsis_rules
this will be performed after the nsis did build the program installer

o  additional_post_nsis_rules64
this will be performed after the nsis did build the program installer for 64bit build

o  allRule_bc_dot_mak

o  globalDefines
allow for the specification of additional defines for stc compilation of prerequisite packages
an subprojects

o  globalDefines_unix
allow for the specification of additional defines for stc compilation of prerequisite packages
an subprojects

o  globalDefines_win32
allow for the specification of additional defines for stc compilation of prerequisite packages
an subprojects

o  localDefines
allow for the specification of additional defines for stc compilation

o  localDefines_unix
allow for the specification of additional defines for stc compilation

o  localDefines_win32
allow for the specification of additional defines for stc compilation

o  localIncludes
allow for the specification of additional include directories

o  localIncludes_unix
allow for the specification of additional include directories

o  localIncludes_win32
allow for the specification of additional include directories

o  primaryTarget
allows the primary make target to be defined in the Make.proto/bc.mak file.

o  primaryTarget_bc_dot_mak
allows the primary make target to be defined in the bc.mak file.

o  primaryTarget_make_dot_proto
allows the primary make target to be defined in the Make.proto file.

o  singleHeaderRuleTemplate_bc_dot_mak
rules for header files (of autoloaded classes)

o  singleHeaderRuleTemplate_make_dot_proto
rules for header files (of autoloaded classes)

o  stcOptimizationOptions
see the stc reference / stc usage for options.
Can be redefined in concrete packages.
For now, the following variants are useful:
+optspace3 most compact code
- use for all gui, application code.

+optinline +optinline2 +inlineNew
fastest code
- use only for computation-intensive classes

o  stcWarningOptions
see the stc reference / stc usage for options.
Can be redefined in concrete packages.
For now, the following variants are useful:
-warn no warnings
-warnNonStandard no warnings about non-standard smalltalk features
-warnUnused no warnings about unused variables

description - contents
o  additionalClassNamesAndAttributes
a List of classes, that belong to the project, but may not be included
in the image (someone may have removed it by purpose)

o  classNamesAndAttributes
a correponding method with real names must be present in my concrete subclasses

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.

o  extensionMethodNamesPairWiseDo: aBlock
enumerates the extension methods into aBlock, passing class name and selector
for each.
New feature: second element of each pair can now be either a selector symbol
(as it used to be) or an array of selectors.

o  ignoredClassNames
can be redefined to suppress some classes from being included in a
generated classNamesAndAttributes spec

description - project information
o  applicationAdditionalIconFileNames
Return the icon-filenames for additional icons of the application
(empty collection if there are none)

o  applicationDocumentTypeDescriptions
Return the OSX document type descriptions.
For deployment, some systems can make use of additional information
on which documents are handled by the application.
This is used eg. for double-clicking on a document in OSX.
If the deployed app can/should handle this, redefine this
to return a collection of instances of ApplicationDocumentTypeDescription.

o  applicationIconFileName
Return the icon-filename for the application (nil if there is none)

o  applicationIconFileNameLinux
Return the icon-filename for the application (nil if there is none)

o  applicationIconFileNameOSX
Return the OSX icon-filename for the application (nil if there is none).
This must be the name of a .icns file, which contains the app-icon in
multiple resolutions.

o  applicationIconFileNameWindows
Return the icon-filename for the application (nil if there is none).
This must be the name of a .ico file, which contains the app-icon in
single or multiple resolutions.

o  applicationReadMeFileNameOSX
Return the OSX filename for a readme file.
If nil, nothing is installed;
if non-nil, it is copied into the dmg folder.

o  companyName
Returns a company string which will appear in <lib>.rc.
Under win32, this is placed into the dll's file-info.
Other systems may put it elsewhere, or ignore it.

o  description
Returns a description string which will appear in vc.def / bc.def

o  fileDescription
Returns a description string which will appear in libName.rc and the rc-file

o  fileMajorVersionNr
Returns a versionNumber which will appear in libName.rc

o  fileMinorVersionNr
Returns a versionNumber which will appear in libName.rc

o  fileReleaseNr
Returns a releaseNumber which will appear in libName.rc

Usage example(s):

        self fileReleaseNr
        exept_expecco_application fileReleaseNr

o  fileRevisionNr
Returns a revisionNumber which will appear in libName.rc

Usage example(s):

    stx_libbasic fileRevisionNr
    stx_libbasic2 fileRevisionNr
    stx_libscm_mercurial fileRevisionNr

o  fileVersion
Returns a fileVersion string which will appear in libName.rc

Usage example(s):

     self fileVersion

o  fileVersionCommaSeparated
Returns a fileVersion string which will appear in libName.rc

o  internalName
Returns a name string which will appear in libName.rc

o  legalCopyright
Returns a copyright string which will appear in <lib>.rc.
Under win32, this is placed into the dll's file-info.
Other systems may put it elsewhere, or ignore it.

Usage example(s):

     self legalCopyright

o  majorVersionNr
Returns a versionNumber which will appear in libName.rc

o  minorVersionNr
Returns a versionNumber which will appear in libName.rc

o  productDate
Returns a product-date string which will appear in libName.rc and the installer file

o  productDescription
Returns a description (for autopackage)

o  productFilename
Returns a filename which will be used as linkname, product file name etc.
The final deployable will be named like this (<fn>.dmg / <fn>Setup.ex / <fn>Install.pkg etc.)

Usage example(s):

     stx_projects_smalltalk productName
     stx_projects_smalltalk productFilename
     stx_libbasic productFilename
     stx_doc_coding_demoConsoleApp productFilename

o  productInstallDir
Returns a default installDir which will appear in <app>.nsi.

Usage example(s):

     stx_projects_smalltalk productInstallDir
     stx_clients_Clock_QlockTwoWatchApplication productInstallDir

o  productInstallDirBaseName
Returns a default installDir which will appear in <app>.nsi.
This is usually not the one you want to keep

o  productLicense
Returns the license (for autopackage)

o  productMaintainer
Returns the maintainer (for autopackage)

o  productName
Returns a product name which will appear in <lib>.rc.
Under win32, this is placed into the dll's file-info.
This method is usually redefined in a concrete application definition

o  productNameAsValidFilename
Returns a filename generated from the product name.
This will be the name of the deployable package (i.e. <fn>.dmg, <fn>Setup.exe, etc.)

Usage example(s):

     'Smalltalk/X' replaceAny:'/\:;.,' with:nil
     stx_doc_coding_demoConsoleApp productName
     stx_doc_coding_demoConsoleApp productNameAsValidFilename

o  productPublisher
Returns a product publisher which will appear in <app>.nsi.

o  productType
Returns the product type for autopackage

o  productVersion
Returns a product version which will appear in libName.rc and the installer file

Usage example(s):

     self productVersion

o  productVersionCommaSeparated
Returns a product version which will appear in libName.rc

Usage example(s):

     self productVersionCommaSeparated
     exept_expecco_application productVersionCommaSeparated

o  productWebSite
Returns a product webSite which will appear in <app>.nsi.

o  releaseNr
Returns a releaseNr which will appear in libName.rc

o  revisionNr
Returns a revisionNr which will appear in libName.rc

o  supportedLanguages
Returns a list of languages that (should be / are) supported by this application or library.
Currently this is only used by lint, to verify that the corresponding languages are
present in the resource files.

Usage example(s):

     stx_goodies_rdoit supportedLanguages
     cg_tools supportedLanguages

o  versionNumber
Returns a version string which will appear in bc.def / vc.def

doc generation
o  autoDocClassNamePatterns
lists patterns for class names for which autodoc html-documentation files
are to be built.
Return #( '*' ) to get doc files for all classes

o  generate_autoDocFiles
generate html documentation for all classes matching the autoDocNamePatterns.
Use this, if you don't want to deliver source code, but still need some documentation
to be deployed.

file generation
o  apspecFilename
for linux

o  basicFileNamesToGenerate
answer a dictionary (filename -> generator method) with all the build-support files,
that have to be generated for this package

Usage example(s):

     stx_libbasic basicFileNamesToGenerate
     stx_libjava basicFileNamesToGenerate

o  fileNamesToGenerate
answer the build-support files that have to be generated as a dictionary of names and generator method

Usage example(s):

      stx_libbasic fileNamesToGenerate

o  forEachFileNameAndGeneratedContentsDo: aTwoArgBlock
for build-support file generation, checkin etc., use this common method which
enumerates all build-support fileNames with their generated contents to be built.

o  forEachFileNameForWhich: filter withGeneratedContentsDo: aTwoArgBlock
for build-support file generation, checkin etc., use this common method which
enumerates all build-support fileNames with their generated contents to be built.

o  forEachFileNameForWhich: filter wothGeneratedContentsDo: aTwoArgBlock
for build-support file generation, checkin etc., use this common method which
enumerates all build-support fileNames with their generated contents to be built.

o  generateFile: filename

o  generateFile: filename confirmMissingClasses: confirmBoolean
if there are missing classes in image, the dependencies cannot be computed.
Warn the user

o  generateFile: filename in: directory
stx_projects_smalltalk generateFile:'package.deps.rake' in: '/tmp'

o  generateRemoveShellScriptOn: aStream
generate a shell script to a cvs remove of broken class filenames.
To be called after the output of #generateRenameShellScript: has been performed

Usage example(s):

       stx_goodies_webServer_htmlTree generateRemoveShellScriptOn:Transcript

o  generateRenameShellScriptOn: aStream
generate a shell script to rename broken class filenames

o  generate_abbrev_dot_stc
for stc: provides abbreviations and namespace information

Usage example(s):

        stx_libbasic generate_abbrev_dot_stc
        DapasXProject generate_abbrev_dot_stc
        DapasX_Datenbasis generate_abbrev_dot_stc
        bosch_dapasx_interactiver_editor generate_abbrev_dot_stc

o  generate_autopackage_default_dot_apspec
stx_projects_smalltalk generate_autopackage_default_dot_apspec

o  generate_bc_dot_mak
DapasXProject generate_bc_dot_mak
DapasX_Datenbasis generate_bc_dot_mak

o  generate_bmake_dot_mak

o  generate_builder_baseline_dot_rbspec
stx_projects_smalltalk generate_builder_baseline_dot_rbspec


o  generate_lccmake_dot_mak

o  generate_loadAll

o  generate_make_dot_proto
stx_libbasic2 generate_make_dot_proto

o  generate_make_dot_spec
DapasXProject generate_make_dot_spec
DapasX_Datenbasis generate_make_dot_spec
bosch_dapasx_kernel_Definition generate_make_dot_spec

o  generate_makefile
stx_libbasic2 generate_makefile

o  generate_mingwmake_dot_mak

o  generate_packageName_dot_rc
bosch_dapasx_datenbasis generate_packageName_dot_rc
bosch_dapasx_hw_schnittstellen generate_packageName_dot_rc
stx_libbasic3 generate_packageName_dot_rc
stx_libwidg3 generate_packageName_dot_rc
stx_libwidg3 productVersion

o  generate_package_dot_deps_dot_rake
stx_libjava generate_dependencies_dot_rake

o  generate_tccmake_dot_mak

o  generate_vcmake_dot_mak

o  nsiFilename
only applications define it

o  protectedFileNames
names of files which should NOT be generated (because they are hand-maintained)
- redefine this to protect a hand-written Make.proto or other handwritten support files

o  rcFilename

o  resourceFilename

file mappings
o  autopackage_default_dot_apspec_mappings
unix here

o  bc_dot_mak_mappings
win32 here

o  bmake_dot_mak_mappings

o  builder_baseline_dot_rbspec_mappings

o  builder_baseline_dot_rbspec_packages

o  classLine_mappings: aClassName

o  common_mappings
must be in specific mapping

o  make_dot_proto_mappings

o  make_dot_spec_mappings

o  makefile_mappings

o  packageName_dot_rc_mappings

o  package_dot_deps_dot_rake_mappings
stx_libjava generate_package_dot_deps_dot_rake

o  replaceMappings: mappings in: fileTemplate
Replaces the defined variable mappings found in a file template with the corresponding information

Usage example(s):

     self replaceMappings: (self nt_dot_def_mappingsFor: self) in: self nt_dot_def

o  st2c: aString

file mappings support
o  classNamesByCategory
answer a dictionary
category -> classNames topological sorted

Usage example(s):

     stx_libbasic classNamesByCategory
     stx_libbasic3 classNamesByCategory
     stx_libview classNamesByCategory
     stx_libjava classNamesByCategory

o  commonSymbolsFlag
only for libraries

o  filenameForClass: classNameOrClass
answer the base filename of the class without suffix

Usage example(s):

        self filenameForClass:HTML::Encoder
        Smalltalk fileNameForClass:HTML::Encoder

o  generateClassLines: classLineTemplate
for the init-file: generate class-init-lines for all classes

o  generateClassLines: classLineTemplate forClasses: classNames
for the init-file: generate class-init-lines for a collection of classes

o  generateClassLines: classLineTemplate forClasses: classNames includeAdditionalClasses: includeAdditionalClasses
for the init-file: generate class-init-lines for a collection of classes

o  generateClassLines_libInit_dot_cc
bosch_dapasx_datenbasis generateClassLines_libInit_dot_cc
bosch_dapasx_kernel generateClassLines_libInit_dot_cc
stx_libbasic3 generateClassLines_libInit_dot_cc

o  generateClasses_make_dot_spec
stx_libbasic generateClasses_make_dot_spec
stx_libbasic3 generateClasses_make_dot_spec
stx_libview generateClasses_make_dot_spec
stx_libboss generateClasses_make_dot_spec

o  generateCleanLeftoverDependencies: whichArchitecture
whichArchitecture is one of #unix or #win32

Usage example(s):

     stx_libbasic generateCleanLeftoverDependencies:#unix
     stx_libbasic generateCleanLeftoverDependencies:#win32

     stx_libtool generateCleanLeftoverDependencies:#unix
     stx_libtool generateCleanLeftoverDependencies:#win32

     stx_libbasic3 generateCleanLeftoverDependencies:#unix
     stx_libbasic3 generateCleanLeftoverDependencies:#win32

     exept_workflow generateCleanLeftoverDependencies:#unix
     exept_workflow generateCleanLeftoverDependencies:#win32
     exept_expecco generateCleanLeftoverDependencies:#unix
     exept_expecco generateCleanLeftoverDependencies:#win32

o  generateCleanLeftoverDependencies_unix

o  generateCleanLeftoverDependencies_win32

o  generateDefinitionClassLine_libInit_dot_cc
for the init-file: generate a single class-init-line for the definition class itself

Usage example(s):

     stx_libbasic generateDefinitionClassLine_libInit_dot_cc

o  generateDependencies: whichArchitecture
whichArchitecture is one of #unix or #win32

Usage example(s):

     stx_libbasic3 generateDependencies:#unix
     stx_libbasic3 generateDependencies:#win32

o  generateDependencies_unix
stx_libbasic3 generateDependencies:#unix
stx_libbasic3 generateDependencies:#win32

o  generateDependencies_win32

o  generateExtensionLine_libInit_dot_cc
generate _stx_137libXXX_extensions_Init(pass,__pRT__,snd);

Usage example(s):

     DapasXProject generateExtensionLine_libInit_dot_cc
     DapasX_Datenbasis generateExtensionLine_libInit_dot_cc
     stx_libtool generateExtensionLine_libInit_dot_cc           '    _stx_137libtool_extensions_Init(pass,__pRT__,snd);'

o  generateExtensionsDefinitionClassLine_libInit_dot_cc
generate 'extern void _stx_137libXXX_extensions_Init(pass,__pRT__,snd);'

Usage example(s):

     DapasXProject generateExtensionsDefinitionClassLine_libInit_dot_cc
     DapasX_Datenbasis generateExtensionsDefinitionClassLine_libInit_dot_cc
     stx_libtool2 generateExtensionsDefinitionClassLine_libInit_dot_cc

o  generateExternalDeclarationLines_libInit_dot_cc
for the init-file:
generate a single external definition for a single class for the definition class itself

Usage example(s):

     stx_libbasic generateExternalDeclarationLines_libInit_dot_cc

o  generateLocalIncludes_unix
bosch_dapasx generateLocalIncludes_unix
bosch_dapasx_datenbasis generateLocalIncludes_unix
stx_libbasic generateLocalIncludes_unix
stx_libview generateLocalIncludes_unix
stx_libtool2 generateLocalIncludes_unix
stx_libui generateLocalIncludes_unix
cg_demos_helloWorld localIncludes_unix

o  generateLocalIncludes_win32
bosch_dapasx_application generateLocalIncludes_win32
bosch_dapasx_datenbasis generateLocalIncludes_win32
stx_libbasic generateLocalIncludes_win32
stx_libview generateLocalIncludes_win32
stx_libtool2 generateLocalIncludes_win32

o  generateObjects_make_dot_spec
stx_libbasic generateObjects_make_dot_spec
stx_libbasic3 generateObjects_make_dot_spec
stx_libview generateObjects_make_dot_spec
stx_libboss generateObjects_make_dot_spec

o  generateRequiredMakePrerequisites_bc_dot_mak
Note: the trailing blank in 'CFLAGS_LOCAL=$(GLOBALDEFINES) '
is required!
Use 'pushd' instead of 'cd', since cd is executed by borland make directly.
'popd' is not needed, since each line is executed in
an own cmd.exe process.
'popd' is not desireable, since it masks a possible
error return from the 'bmake'.

Usage example(s):

     exept_expecco_application generateRequiredMakePrerequisites_bc_dot_mak
     alspa_batch_application generateRequiredMakePrerequisites_bc_dot_mak

o  generateRequiredMakePrerequisites_make_dot_proto
cg: changed to not go and remake librun

Usage example(s):

     exept_expecco_application generateRequiredMakePrerequisites_make_dot_proto
     alspa_batch_application generateRequiredMakePrerequisites_make_dot_proto

o  generateRequiredMakeReferences_bc_dot_mak
Note: the trailing blank in 'CFLAGS_LOCAL=$(GLOBALDEFINES) '
is required!
Use 'pushd' instead of 'cd', since cd is executed by borland make directly.
'popd' is not needed, since each line is executed in
an own cmd.exe process.
'popd' is not desierable, since it masks a possible
error return from the 'bmake'.

Usage example(s):

     exept_expecco_application generateRequiredMakeReferences_bc_dot_mak
     alspa_batch_application generateRequiredMakeReferences_bc_dot_mak

o  generateRequiredMakeReferences_make_dot_proto
these have been already built in preReq

Usage example(s):

     exept_expecco_application generateRequiredMakeReferences_make_dot_proto
     alspa_batch_application generateRequiredMakeReferences_make_dot_proto

o  generateSubDirectories
exept_expecco generateSubDirectories

o  generate_definitionClassLine_libInit_dot_cc
for the init-file: generate a single class-init-line for the definition class itself

Usage example(s):

     stx_libbasic generate_definitionClassLine_libInit_dot_cc

o  headerFileOutputArg
Every header file is left locally in its lib-dir

o  objectLine_make_dot_spec_mappings: aClassName

o  subProjectBmakeCalls
generate submake-calls for borland bcc

o  subProjectLCCmakeCalls
generate submake-calls for lcc

o  subProjectMakeCallsUsing: callString
for xxxmake.bat files

o  subProjectMingwmakeCalls
generate submake-calls for mingw

o  subProjectTCCmakeCalls
generate submake-calls for tcc

o  subProjectVCmakeCalls
generate submake-calls for visual-C

file templates
o  autopackage_default_dot_apspec
for linux's autopackage

o  bc_dot_mak
answer a template for the bc.mak makefile.
Any variable definition %(Variable) will be later replaced by the mapping.
$% characters have to be duplicated.
Only needed for WIN

** This method must be redefined in concrete classes (subclassResponsibility) **

o  bmake_dot_mak
the template code for the bmake.bat file
Notice: duplicate %'s if they are needed as such in the generated file

o  builder_baseline_dot_rbspec
For rake-base automatic builder

o  builder_baseline_dot_rbspec_postamble

o  builder_baseline_dot_rbspec_preamble

o  classExternalDeclarationLine_libInit_dot_cc

o  classLine_libInit_dot_cc

o  extensionDefinitionLine_libInit_dot_cc
template for an extern definition of the extension_Init function

o  extensionLine_libInit_dot_cc
template for a call of the extension_Init function

o  generate_osx_info_dot_plist
template for the info.plist file, which is included in an OS X deployment

o  lccmake_dot_mak
the template code for the lccmake.bat file

o  make_dot_proto
the template code for the make.proto file

** This method must be redefined in concrete classes (subclassResponsibility) **

o  make_dot_spec
' at ',Timestamp now printString,

o  makefile

o  mingwmake_dot_mak
the template code for the mingwmake.bat file

o  objectLine_make_dot_spec

o  osx_info_dot_plist_dictionary
template for the info.plist file, which is included in an OS X deployment

o  packageName_dot_rc
the template code for the <libName>.rc file.
Only used for WIN

Usage example(s):

     stx_libbasic3 packageName_dot_rc
     stx_libbasic3 generate_packageName_dot_rc

o  package_dot_deps_dot_rake

o  tccmake_dot_mak
the template code for the tccmake.bat file

o  vcmake_dot_mak
the template code for the vcmake.bat file

instance creation
o  definitionClassForMonticelloPackage: aMonicelloPackagename
( an extension from the stx:libcompat package )
self definitionClassForMonticelloPackage:'foobar'

o  definitionClassForMonticelloPackage: aMonicelloPackagename createIfAbsent: createIfAbsent
( an extension from the stx:libcompat package )
if the squeak-stuff is loaded, use it.

Usage example(s):

     self definitionClassForMonticelloPackage:'foobar'
     self definitionClassForMonticelloPackage:'foobar' createIfAbsent:true

o  definitionClassForPackage: aPackageID
given a packageID (such as 'stx:libfoo/bar'), lookup the corresponding peoject definition class.
Return it, or nil if not present

Usage example(s):

     ProjectDefinition definitionClassForPackage:'stx:libbasic'
     ProjectDefinition definitionClassForPackage:'stx:libfoobarBaz'

o  definitionClassForPackage: aPackageID createIfAbsent: doCreateIfAbsent

o  definitionClassForPackage: aPackageID createIfAbsent: doCreateIfAbsent projectType: typeOrNil
setup before prerequisites are defined

o  definitionClassForPackage: newProjectID projectType: typeOrNil createIfAbsent: createIfAbsent

o  definitionClassForType: type
answer the class that describes a give project type

o  newForPackage: packageID

o  newNamed: newName package: packageID
for now, we are strict.

loading
o  checkForLoad
raise an error, if the package is not suitable for loading

o  ensureFullyLoaded
ensure that all classes and extensions are loaded properly.
This is normally no problem for compiled classLibs - however, if a package
has only be installedAsAutoloaded, some classes might want to ensure that
when being loaded themself.

Usage example(s):

     stx_libbasic ensureFullyLoaded

o  load
load the project
Answer true, if new classes have been installed for this package,
false if the package's classes have been already present.

o  loadAsAutoloaded: asAutoloaded
load the project.
If asAutoloaded == true, install all new classes as autoloaded.
Answer true, if new classes have been installed for this package,
false if the package's classes have been already present.

o  unloadPackage
unload the project.
Fails if there are still instances of any of my classes in the system

misc ui support
o  iconInBrowserSymbol
( an extension from the stx:libtool package )
the browser will use this as index into the toolbariconlibrary

private
o  abbrevs
return a dictionary containing my abbreviations;
this dictionary is read from my project-directory's abbrev.stc file,
and cached for future use

o  additionalClassAttributesFor: aClass
Answers additional set of class attributes for given class
Individual project definitions may override this method, but
overriding method should always merge its attributes with result
of 'super additionalClassAttributesFor: aClass'.

Here, we add #autoload attributes to all test cases and
test resources, as they are not necessary for the package
and should not be compiled (because of unwanted dependency
on stx:goodies/sunit package)

But not make them autoloaded when the package is separate
test-package - by conventions such package should by named
#'module:package/subpackage/tests'

Usage example(s):

        stx_libbasic additionalClassAttributesFor: Object
        stx_libtool additionalClassAttributesFor: Tools::NavigationHistoryTests
        stx_goodies_sunit additionalClassAttributesFor: TestCase
        stx_goodies_petitparser_tests additionalClassAttributesFor: PPAbstractParseTest


        stx_libtool classNamesAndAttributes_code_ignoreOldEntries:true ignoreOldDefinition: true

o  checkIfClassesArePresent
check if all classes defined by this project are present and
offer a dialog to abort the current operation if not

o  classNamesAndAttributesAsSpecArray
given a classNamesAndAttributes array, make this a spec array (array of arrays).
This decompresses class-name entries into a one-element array for easier processing

o  classNamesAndAttributesDo: aBlock

o  classNamesAndAttributesFromSpecArray: aSpecArray
given a spec array (array of arrays), make this a classNamesAndAttributes array
as stored literally in the method.
This compresses single element array-elements into plain names
(to save code in the compiled binaries) and especially sorts them by load/compile order

o  compile: someCode categorized: category
(comment from inherited method)
compile code, aString for this class;
if successful update the method dictionary.
Returns the new method or nil (on failure).

o  compile: someCode categorized: category using: compilerOrNil

o  compiled_classes

o  compiled_classesDo: aBlock

o  compiled_classesForPlatform: arch
stx_libbasic compiled_classesForArchitecture:#win32
stx_libbasic compiled_classesForArchitecture:#macos
stx_libbasic compiled_classesForArchitecture:#unix

o  compiled_classes_common
isBehavior

o  cvsRevision
not yet pubplished

Usage example(s):

     self cvsRevision
     stx_libbasic3 cvsRevision

o  defaultClassAttributesFor: aClass
Answers default set of class attributes for given class.
This is internal method only, to per-project customization
please override either #additionalClassAttributes or
#additional classAttributesFor:

o  inconsistency: message
self searchForNeverCompiledSuperclasses
DapasX_Datenbasis searchForNeverCompiledSuperclasses

o  makeOSIncludesWith: fileSeparator from: aString
self makeOSIncludesWith:$/ from:'-I$(TOP)/foo/bar'
self makeOSIncludesWith:$\ from:'-I$(TOP)/foo/bar'

o  makeUnixIncludes: aString

o  makeWin32Includes: aString

o  mergeClassAttributes: attr1 with: attr2

o  mergeDefaultClassAttributesFor: aClass with: attributes

o  namesAndAttributesIn: aCollection do: aBlock

o  searchForClasses
answer all non-private classes that belong to this project.
They are sorted in load order

Usage example(s):

     stx_libbasic3 searchForClasses
     stx_goodies_webServer_htmlTree searchForClasses

o  searchForClassesWithProject: aProjectID
answer all public and private classes belonging to aProjectID

Usage example(s):

    self searchForClassesWithProject: #'exept:ctypes'

o  searchForExtensions
self searchForExtensions
DapasXProject searchForExtensions
DapasX_Datenbasis searchForExtensions
stx_libtool searchForExtensions

o  searchForExtensionsWithProject: aProjectID
search for any class which has extensions from aProjectID.
Return the extension-methods sorted by classname-selector

Usage example(s):

     self searchForExtensionsWithProject:#'bosch:dapasx'
     self searchForExtensionsWithProject:#'cg:oyster'
     self searchForExtensionsWithProject:#'stx:libboss'

o  searchForProjectsWhichProvideHeaderFiles
(package startsWith:'stx:') not

Usage example(s):

     stx_libtool searchForProjectsWhichProvideHeaderFiles
     cg_demos_helloWorld searchForProjectsWhichProvideHeaderFiles
     cg_tools_emulators_freecell searchForProjectsWhichProvideHeaderFiles

o  searchForSiblingProjects
answer all the packages (package names) having the my parent package

Usage example(s):

     self searchForSiblingProjects
     bosch_dapasx_Application searchForSiblingProjects
     stx_goodies_refactoryBrowser_changes searchForSiblingProjects

o  searchForSubProjects
answer all packages (package names), that are my subProjects

Usage example(s):

     self searchForSubProjects
     bosch_dapasx_Application searchForSubProjects
     stx_goodies_refactoryBrowser_changes searchForSubProjects

o  setupForType: typeOrNil

o  shouldExcludeTest: test

o  verbose: aBoolean
enable/disable diagnostic output, which gives more detail on why package loading fails

Usage example(s):

     self verbose:true
     self verbose:false

private-extension handling
o  extensionOverwriteInfo

o  fetchSlotsFrom: myFirstIncarnation
this is invoked in a just loaded instance of myself,
to fetch the safe and extensionInfo from my first incarnation

o  hasSavedOverwrittenMethods
true, if any of my methods was overwritten by another loaded package.
These methods are now in my safe

o  methodOverwrittenBy: anExtensionMethod
return the (hidden) original method, which was located in another package
and which got overwritten by one of my extension methods. Nil if there is none.

o  rememberOverwrittenExtensionMethods
before loading, tell other packages to keep a safe reference to any method
which gets overloaded by me, and also remember here, whom I have overloaded.
This allows for two things:
a) correct fileout of the other base-package (for example, when checking in any of its class)
b) correct unloading of myself

o  rememberOverwrittenMethod: oldMethod inClass: aClass
invoked from another projectDefinition, when that package is about to be loaded
and about to overwrite one of my methods.
I will save the method locally, to allow for correct fileout of this class/project or
to correctly reestablish my methods when the other package is unloaded later.

o  restoreOverwrittenExtensionMethods
after unloading, tell other packages to restore any saved reference to any method
which got overloaded by me.
Unfinished!

o  safeForOverwrittenMethods

o  savedOverwrittenMethodForClass: aClass selector: aSelector
return one of my saved original methods

o  savedOverwrittenMethods
return my saved original methods

private-loading
o  checkPrerequisitesForLoading
check if I can be loaded - i.e. if all classes to be extended are already loaded.
Raise an error if not

Usage example(s):

     stx_libjavascript checkPrerequisitesForLoading

o  executeHooks: hookSymbol
Execute all hooks annotated by the given hook-symbol.
Currently supported hooks are: #preLoad, #postLoad, #preUnload.

o  loadAllAutoloadedClasses

o  loadAllClassesAsAutoloaded: asAutoloaded
load (fileIn) classes that should be present -
install as autoloaded classes marked to be autoloaded.
If asAutoloaded == true, all classes will be installed as autoloaded, even if not marked.

Answer true, if classes have been loaded

o  loadAllClassesAsAutoloaded: asAutoloaded languages: langs
load (fileIn) classes in given languages that should be present -
install as autoloaded classes marked to be autoloaded.
If asAutoloaded == true, all classes will be installed as autoloaded, even if not marked.
langs should be collection of ProgrammingLanguage available in the system.

Answer true, if classes have been loaded

o  loadClass: className asAutoloaded: asAutoloaded language: programmingLanguage
Handle smalltalk classes specially to provide backward compatibility

o  loadClassLibrary
try to load a binary class library
Raise an exception on failure.

o  loadExtensions
load extension methods - do not load if they are already present

o  loadExtensionsForLanguage: lang
load extension methods for given programming language

o  loadMandatoryPreRequisitesAsAutoloaded: asAutoloaded
load those packages which are required for loading.
Called after my definition has been loaded, but before the rest of the
package is.

o  loadPackages: aListOfPackages asAutoloaded: asAutoloaded
load some packages (at least the projectDefinitions and their extensions).
If asAutoloaded == true, classes will be only installed as autoloaded.

o  loadPreRequisitesAsAutoloaded: asAutoloaded
load other packages (at least the projectDefinitions and their extensions)

o  loadSubProjects
load other packages (at least the projectDefinitions and their extensions)

o  loadSubProjectsAsAutoloaded: asAutoloaded
load other packages (at least the projectDefinitions and their extensions)

o  old_loadAllClassesAsAutoloaded: asAutoloaded
load (fileIn) classes that should be present -
install as autoloaded classes marked to be autoloaded.
If asAutoloaded == true, all classes will be installed as autoloaded, even if not marked.

Answer true, if classes have been loaded

o  unloadAllClasses

o  unloadClassLibrary

o  unloadSubProjects
unload other packages

o  update: anAspectSymbol with: argument from: changedObject
when any of my class methods is changed, we mark the project as unloaded.
May be some more classes have to be loaded

private-prerequisites
o  addReferencesToClassesFromGlobalsIn: aSetOfClasses to: usedClassReasons
helper for searchForPreRequisites

o  addReferencesToClassesFromGlobalsInMethods: someMethods to: usedClassReasons
helper for searchForPreRequisites

o  addReferencesToExtensionMethodsIn: someClasses to: usedMethodReasons
helper for searchForPreRequisites: search for sends of a selector which
is defined as an extension method (in the set of passed-in methods).
If found, add the extension method and a reason string to usedReasons.
This should find especially sends to extension methods from libcompat.

Note: methods may be both defined as extension method and non-extension method.
If this is the case, mark the extension method as referenced,
with a comment, that it is also defined as a non-extension method.

o  allMandatoryPreRequisites
answer all (recursive) mandatory prerequisite project ids of myself - in random order.

Usage example(s):

     stx_libbasic allMandatoryPreRequisites
     stx_libbasic2 allMandatoryPreRequisites
     stx_libview2 allMandatoryPreRequisites
     stx_libcomp allMandatoryPreRequisites
     exept_expecco_application allMandatoryPreRequisites

o  allMandatoryPreRequisitesSorted

o  allPreRequisites
answer all (recursive) prerequisite project ids of myself - in random order.

Usage example(s):

     stx_libbasic allPreRequisites
     stx_libbasic2 allPreRequisites
     stx_libview2 allPreRequisites
     ubs_application allPreRequisites
     ubs_application allPreRequisitesSorted
     exept_expecco_application allPreRequisites
     exept_expeccoNET_application allPreRequisites
     alspa_batch_application allPreRequisites

o  allPreRequisites: aSelector
answer all (recursive) prerequisite project ids of myself - in random order.
aSelector determins, which prerequisites are to be fetched.

o  allPreRequisites: aSelector withParentDo: aBlock
answer all (recursive) prerequisite project ids of myself - in random order.
If we exclude a project, but one of our prerequisite projects depends on it,
then what ????

o  allPreRequisitesSorted

o  allPreRequisitesSorted: aSelector
answer all the prerequisites of this projects sorted in
the order they are needed.
Use this to e.g. compile packages in the dependency order

Usage example(s):

     stx_libbasic allPreRequisitesSorted
     stx_libbasic2 allPreRequisitesSorted
     stx_libwidg2 allPreRequisitesSorted
     exept_expecco allPreRequisitesSorted
     alspa_batch_application allPreRequisitesSorted
     exept_expecco_application allPreRequisitesSorted:#effectiveMandatoryPreRequisites

o  allPreRequisitesWithMandatorySorted
a list of all prerequisites (mandatory and non-mandatory,
with the mandatory ones coming first and being sorted by dependency

Usage example(s):

        exept_expecco_application allPreRequisitesWithMandatorySorted

o  allReferences
answer all (recursive) projects to which I refer - in random order.

Usage example(s):

     stx_libbasic allReferences
     stx_libbasic2 allReferences
     stx_libview2 allReferences
     ubs_application allReferences
     ubs_application allReferences
     exept_expecco_application allReferences
     exept_expeccoNET_application allReferences
     alspa_batch_application allReferences

o  effectiveMandatoryPreRequisites
get the preRequisites, that are not excluded, which are needed for loading
and compiling (i.e. which must be present BEFORE)

o  effectivePreRequisites
get the preRequisites, that are not excluded.
This method appears to be obsolete, because its functionality
is now included in #preRequisites.
But is to be kept for backward compatibilty with old existing subclasses.

o  searchForPreRequisites
answer a Dictionary where the keys are the prerequisite package for this package
and the values are a Set of reasons, why each package is required.
The first entry in the array are the mandatory prereqs (required for compilation),
the second entry are the referenced prereqs (required for loading).
Referenced prereqs are due to elements accessed at execution time (such as globals)

Usage example(s):

     self searchForPreRequisites
     stx_libbasic3 searchForPreRequisites
     bosch_dapasx_Application searchForPreRequisites
     bosch_dapasx_pav_browser searchForPreRequisites

o  searchForPreRequisites: packageId
answer an array containing two Dictionaries where the keys are the prerequisite package for the given package
and the values are a Set of reasons, why each key package is required.
The first entry in the array are the mandatory prereqs (required for compilation),
the second entry are the referenced prereqs (required for loading).
Referenced prereqs are due to elements accessed at execution time (such as globals)

Usage example(s):

     self searchForPreRequisites
     self searchForPreRequisites:#'stx:libwidg3'
     self searchForPreRequisites:#'stx:libtool'
     bosch_dapasx_Application searchForPreRequisites
     bosch_dapasx_pav_browser searchForPreRequisites

o  searchForPreRequisites: packageId withSubProjects: withSubProjectsBoolean
answer an array containing two Dictionaries where the keys are the prerequisite package for the given package
and the values are a Set of reasons, why each key package is required.
The first entry in the array are the mandatory prereqs (required for compilation),
the second entry are the referenced prereqs (required for loading).
Referenced prereqs are due to elements accessed at execution time (such as globals)

Usage example(s):

     self searchForPreRequisites:#'stx:libwidg3'
     bosch_dapasx_Application searchForPreRequisites
     bosch_dapasx_pav_browser searchForPreRequisites
     self searchForPreRequisites:#'stx:goodies/json' withSubProjects:false

queries
o  allClassNames

o  allClasses

o  allExtensionClasses
answer the set of classes, which are extended by the package.
includes all superclasses of the extended classes

Usage example(s):

     stx_libboss allExtensionClasses

o  autoloaded_classNames
the opposite of compiled class names

o  canHaveExtensions
return true, if this class allows extensions from other packages.
Private classes, namespaces and projectDefinitions don't allow this

Usage example(s):

     Smalltalk allClasses select:[:each | each canHaveExtensions not]

o  classNamed: aClassName
answer one of my classes.
This makes me look a bit like a namespace (which I am not currently);
in preparation for a future require package mechanism...

o  classNames
answer an array containing all the class names of the project's classes

Usage example(s):

     stx_libhtml classNames
     stx_libhtml classNamesAndAttributesAsSpecArray

o  classNamesForWhich: aBlock
a correponding method with real names is generated in my subclasses

o  classes
list my classes.
Project must be loaded - otherwise an error is reported here.
Use #classNames if you are only interested in the names

Usage example(s):

     stx_libbasic3 classNames
     stx_libbasic3 classes

o  compiled_classNames
the opposite of autoloaded class names

o  compiled_classNamesForPlatform
answer the classes to be compiled only for the current platformName

o  compiled_classNamesForPlatform: platformName
answer the classes to be compiled only for platformName
platformName is one of #unix, #win32, #vms or #osx (OperatingSystem platformName)

o  compiled_classNames_common
classes to be compiled for any platform

o  compiled_classNames_unix
class, only to be compiled under unix

o  compiled_classNames_windows
class, only to be compiled under windows

o  compiled_classesForPlatform
list my classes for the current platform.
Project must be loaded - otherwise an error is reported here.
Use #classNames if you are only interested in the names

Usage example(s):

     stx_libbasic compiled_classesForPlatform
     stx_libbasic classes

o  extensionClasses
answer the set of classes, which are extended by the package

Usage example(s):

     stx_libboss extensionClasses

o  extensionClassesWithSuperclasses: withSuperclassesBoolean
answer the set of classes, which are extended by the package

o  extensionMethods
list my extension methods.
Project must be loaded - otherwise an error is reported here.
Use #extensionMethodsNames if you are only interested in the names

Usage example(s):

     stx_libbasic2 extensionMethodNames
     stx_libbasic2 extensionMethods

o  extensionPackages
answer the set of packages, which are extended by this package

Usage example(s):

        stx_libboss extensionPackages

o  hasAllClassesFullyLoaded
return true, if all classes are present and loaded (not autoloaded)

o  hasAllClassesLoaded
return true, if all classes are present (although, some might be autoloaded)

o  hasAllClassesLoaded: checkIfFullyLoaded
check if all classes for this platform are present.
If checkIfFullyLoaded is true, they must be fully loaded; that means: not autoloaded

o  hasAllCompiledClassesFullyLoaded
return true, if all compiled classes are present and loaded

o  hasAllCompiledClassesLoaded: checkIfFullyLoaded
check if all compiled classes for this platform are present.
If checkIfFullyLoaded is true, they must be fully loaded, that is not autoloaded

o  hasAllExtensionsLoaded
answer true, if all extensions of this package have been loaded.
This is a query - so no side effects please

o  hasClasses: classNames loaded: checkIfFullyLoaded
answer true, if all classes referenced by classNames have been loaded
into the image. If checkIfFullyLoaded, classes installed as autoloaded
are not considered

o  hasExtensionMethods

o  hasPostLoadAction
true if postLoadAction has been redefined

o  hasPostUnloadAction
true if postUnloadAction has been redefined

o  hasPreLoadAction
true if preLoadAction has been redefined

o  hasPreUnloadAction
true if preUnloadAction has been redefined

o  projectType

** This method must be redefined in concrete classes (subclassResponsibility) **

o  reasonForNotSupportedOnPlatform
answer a reason string, why the package is not supported on this platform
(if it is not, i.e. if supportedByPlatform returns false)

o  supportedOnPlatform
answer false, if this package is not suitable for
the current platform. The default here returns true.
Only to be redefined in packages which are definitely not valid
for the given platform. For example, the OLE package is only
usable under windows

o  whoReferences: aPackageString
answer, which package references directly or indirectly a package defined by aPackageString

Usage example(s):

      self whoReferences:'stx:libview3'
      self whoReferences:'stx:libwidg3'
      self whoReferences:'stx:libbasic'

o  whoReferencesSorted: aPackageString
answer, which package references directly or indirectly a package define by aPackageString.
Sort the result, so that the most direct referrers are at the top

Usage example(s):

      self whoReferencesSorted:'stx:libview3'
      self whoReferencesSorted:'stx:libwidg3'
      self whoReferencesSorted:'stx:libbasic'

queries-privacy
o  showClassDocumentationOf: aClass
used by the HTMLDoc-generator to ask if a classes' protocol is to be documented
or hidden.
(used for expecco, to suppress documentation of workflow- and expecco classes
in the expecco-class browser)

sanity checks
o  validateDescription
perform some consistency checks (set of classes in project same as those listed in description);
called before checking in build support files.
Somewhat obsolete: use the ProjectChecker, which does more checks

Usage example(s):

     exept_expecco_application validateDescription
     squeak_vmMaker validateDescription

o  validateOrderOfClasses
check if the project's classes are listed in the correct dependency order in the classList.
This would be required, if the generated makefile would compile files in that order,
and superclasses must be compiled before subclasses (for the header files).
However, the makefile list is generated by a separate mechanism, so that is not requiered.

Usage example(s):

     stx_goodies_refactoryBrowser_lint validateOrderOfClasses
     squeak_vmMaker validateOrderOfClasses

testing
o  isAbstract
Modified (format): / 20-08-2011 / 22:47:46 / cg

o  isApplicationDefinition
true iff an application-package (i.e. not a library).
Applications have a main and startup for standalon start

o  isAutoloaded: aClassOrClassName
'stx:goodies/soap/xe/tests' asPackageId projectDefinitionClass
isAutoloaded:#'SOAP::XeAllTests'

o  isConsoleApplication
Used with WIN32 only (i.e. affects bc.mak).
Return true, if this is a console application.
Console applications have stdout and stderr and open up a command-window
when started. Only console applications can interact with the user in the
command line window.

o  isFolderForProjectsDefinition
true iff an 'empty' project which only holds subprojects,
but no own classes. Examples are stx, exept, etc.

o  isFullyLoaded
as the inherited query isLoaded only refers to a single classes load status,
this one returns true iff the whole project (all classes plus all extensions) is loaded

o  isGUIApplication
true iff a GUI application.
Will include startup code to open a display

o  isLibraryDefinition
true iff a library.
Will NOT include startup code, and can only be loaded into or
linked with an application

o  isPluginDefinition
an attribute for end-user-application plugins (eg. expecco)

o  isProjectDefinition
concrete i.e. not abstract


Private classes:

    AbbrevEntry
    ApplicationDocumentTypeDescription


ST/X 7.7.0.0; WebServer 1.702 at 20f6060372b9.unknown:8081; Sat, 23 Nov 2024 08:02:27 GMT