Class: LibraryDefinition

• Inheritance
• Class protocol
  • description - compilation
  • description - project information
  • file generation
  • file mappings
  • file mappings support
  • file templates
  • misc ui support
  • obsolete
  • queries
  • sanity checks
  • testing

Inheritance:

   Object
   |
   +--ProjectDefinition
      |
      +--LibraryDefinition
         |
         +--stx_goodies_authentication
         |
         +--stx_goodies_communication
         |
         +--stx_goodies_refactoryBrowser_parser
         |
         +--stx_goodies_webServer
         |
         +--stx_goodies_webServer_comanche
         |
         +--stx_goodies_webServer_comanche_stt
         |
         +--stx_goodies_webServer_comanche_swiki
         |
         +--stx_goodies_webServer_htmlTree
         |
         +--stx_goodies_webServer_ui
         |
         +--stx_goodies_xml_stx
         |
         +--stx_goodies_xml_vw
         |
         +--stx_libbasic
         |
         +--stx_libbasic2
         |
         +--stx_libbasic3
         |
         +--stx_libcomp
         |
         +--stx_libcompat
         |
         +--stx_libhtml
         |
         +--stx_libjavascript
         |
         +--stx_libtool
         |
         +--stx_libui
         |
         +--stx_libview
         |
         +--stx_libview2
         |
         +--stx_libwidg
         |
         +--stx_libwidg2
         |
         +--stx_libwidg3

Package:

stx:libbasic

Category:

System-Support-Projects

Version:

rev: 1.136 date: 2019/03/08 11:17:16

user: cg

file: LibraryDefinition.st directory: libbasic

module: stx stc-classLibrary: libbasic

Class protocol:

 primaryTarget

the primary make target in Make.proto/bc.mak

 description

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

 fileDescription

Return a description string which will appear in nt.def / bc.def and the rc-file

 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

 productType

Returns the product type for autopackage

 basicFileNamesToGenerate

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

 generate_libInit_dot_cc

stx_libbasic2 generate_libInit_dot_cc
bosch_dapasx_datenbasis generate_libInit_dot_cc
bosch_dapasx_application generate_libInit_dot_cc

 bc_dot_mak_mappings

(self package copyFrom:(self package lastIndexOfAny:':/')+1),'.$(RES)'.

 extensionLine_libInit_dot_cc_mappings

 libInit_dot_cc_mappings

stx_libbasic libInit_dot_cc_mappings

 make_dot_proto_mappings

 commonSymbolsFlag

some libraries are compiled with COMMONSYMBOLS -
This saves a lot of space in the generated dll/so files;
However, it also requires the librun to be rebuilt, whenever one of
the commonSymbols-libs changes.
Therefore, NEVER do this for end-user or application libraries;
ONLY do it for a subset of the predefined, eXept-provided standard stx libraries

 generateExtensionLine_libInit_dot_cc

DapasXProject generateExtensionLine_libInit_dot_cc
DapasX_Datenbasis generateExtensionLine_libInit_dot_cc

 bc_dot_def

the template code for the bc.def file

 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

 extensionLine_libInit_dot_cc

 libInit_dot_cc

the template code for the libInit.cc file

 make_dot_proto

,' at ',Timestamp now printString

 iconInBrowserSymbol
( an extension from the stx:libtool package )

the browser will use this as index into the toolbariconlibrary

 lib_dot_rc

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

 definitionClassOfApplicationBundle

Return the applicationDefinition of the applicationBundle or nil.
This is the applicationDefinition of the package which gets actually deployed.
For example, for all stx libraries, this will be stx_projects_smalltalk.
For expecco, this would be exept_expecco_application.
The algorithm here follows the parent hierarchy (not the class hierarchy) of the package name.
Some classes may explicitly redefine this (if the folder structure is not hierarchical).
This information is currently used for automatic check of language translations.

Notice: libraries which are used by more than one project, should only return the one
which is their 'natural' bundle - usually defined by the position in the package hierarchy.
This is a little experimental - may change.

usage example(s):

exept_expecco definitionClassOfApplicationBundle

 isAbstract

 projectType

 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.

 searchForInconsistencies

self searchForInconsistencies
DapasX_Datenbasis searchForInconsistencies

 searchForNeverCompiledSuperclasses

self searchForNeverCompiledSuperclasses
DapasX_Datenbasis searchForNeverCompiledSuperclasses

 isLibraryDefinition

stx_libboss isLibraryDefinition
ProjectDefinition isLibraryDefinition
LibraryDefinition isLibraryDefinition