Re: Osclass Premium Themes Nulled Definition
Nettie Rosier
EPICS software can be divided into multiple areas. Examples of areas are EPICS base itself, EPICS extensions, and simple orcomplicated IOC applications. Each may be maintained separately.Different areas can be on different releases of externalsoftware such as EPICS base releases.
Files installed during the build are installed into subdirectories of aninstallation directory which defaults to $(TOP), the directory.For base, extensions, and IOC applications, the default value can bechanged in the configure/CONFIG_SITE file. The installation directoryfor the EPICS components is controlled by the definition ofINSTALL_LOCATION
A corresponding set of configuration files in the/configure directory of a non-base directory structure to be built. ThemakeBaseApp.pl and makeBaseExt.plscripts create these configuration files. Many of these files justinclude a file of the same name from the base/configure directory.
You can build on multiple host systems and for multiple cross targetsystems using a single EPICS directory structure. The intermediate andbinary files generated by the build will be created in separateO.* subdirectories and installed into the appropriateseparate host or target install directories. EPICS executables andscripts are installed into the$(INSTALL_LOCATION)/bin/ directories. Librariesare installed into $(INSTALL_LOCATION)/lib/. Thedefault definition for $(INSTALL_LOCATION) is$(TOP) which is the root directory in the directorystructure. Architecture dependant created files (e.g. object files) arestored in O. source subdirectories, andarchitecture independent created files are stored inO.Common source subdirectories. This allows objects formultiple cross target architectures to be maintained at the same time.
To build EPICS base for a specific host/target combination you must havethe proper host/target c/c++ cross compiler and target header files,CROSS_COMPILER_HOST_ARCHS must empty or include the hostarchitecture in its list value, theCROSS_COMPILER_TARGET_ARCHS variable must include thetarget to be cross-compiled, and the base/configure/ os directory musthave the appropriate configure files.
For Unix host builds you also need touch, cpp, cp, rm, mv, and mkdir inyour search path and /bin/chmod must exist. On some Unix systems you mayalso need ar and ranlib in your path, and the c compiler may require ldin your path.
The startup directory in EPICS base contains a perl script,EpicsHostArch.pl, which can be used to defineEPICS_HOST_ARCH. This script can be invoked with a commandline parameter defining the alternate compiler (e.g. if invokingEpicsHostArch.pl yields solaris-sparc, then invoking EpicsHostArch.plgnu will yield solaris-sparc-gnu).
To configure each host system for your site, you may override thedefault definitions in the configure/os directory by adding a new filewith override definitions. The new file should have the same name as thedistribution file to be overridden except CONFIG in the name is changedto CONFIG_SITE.
To configure each target system, you may override the defaultdefinitions in the configure/os directory by adding a new file withoverride definitions. The new file should have the same name as thedistribution file to be overridden except CONFIG in the name is replacedby CONFIG_SITE.
To configure EPICS base for building with R3.13 extensions and iocapplications, you must modify the default definitions in thebase/config/CONFIG_SITE* files to agree with sitedefinitions you made in base/configure and base/configure/os files.Youmust also modify the following tow macros in thebase/configure/CONFIG_SITE file:
The base/configure directory contains files with the default build definitionsand site specific build definitions. The extensions/configure directory containsextension specific build definitions (e.g. location of X11 and Motif libraries)and include lines for the base/configure files. Likewise, the/configure directory contains application specific builddefinitions and includes for the application source files. Build definitionssuch as CROSS_COMPILER_TARGET_ARCHS can be overridden in an extension orapplication by placing an override definition in the/configure/CONFIG_SITE file.
Every /configure directory contains a RELEASE file. RELEASEcontains a user specified list of other directory structurescontaining files needed by the current , and may also includeother files to take those definitions from elsewhere. The macros definedin the RELEASE file (or its includes) may reference other definedmacros, but cannot rely on environment variables to provide definitions.
When make is executed, macro definitions for include, bin, and librarydirectories are automatically generated for each external definition given in the RELEASE file. Also generated are includestatements for any existing RULES_BUILD files, cfg/RULES*files, and cfg/CONFIG* files from each external listed in theRELEASE file.
RELEASE_DBDFLAGS will appear on the command lines for thedbToRecordTypeH, mkmf.pl, and dbExpand tools, andRELEASE_INCLUDES will appear on compiler command lines.CAMAC_LIB and CAMAC_BIN can be used in aMakefile to define the location of needed scripts, executables, objectfiles, libraries or other files.
For directory structures created by makeBaseApp.pl, an EPICSbase perl script, convertRelease.pl can perform consistency checks forthe external definitions in the RELEASE file and its includes aspart of the level build. Consistancy checks are controlled byvalue of CHECK_RELEASE which is defined in/configure/CONFIG_SITE. CHECK_RELEASE can be setto YES, NO or WARN, and if YES (the default value), consistency checkswill be performed. If CHECK_RELEASE is set to WARN thebuild will continue even if conflicts are found.
You should always do a gnumake clean uninstall in the directoryBEFORE adding, changing, or removing any definitions in theconfigure/RELEASE* files and then a gnumake at the top level AFTERmaking the changes.
All definitions in /configure/RELEASE must result in completepath definitions, i.e. relative path names are not permitted. If yoursite could have multiple releases of base and other support components installed at once, these path definitions should contain arelease number as one of the components. However as the RELEASE file isread by gnumake, it is permissible to use macro substitutions to definethese pathnames, for example:
Build creates two type of makefile targets: Host and Ioc. Host targetsare executables, object files, libraries, and scripts which are not partof iocCore. Ioc targets are components of ioc libraries, executables,object files, or iocsh scripts which will be run on an ioc.
Each supported target system has a VALID_BUILDS definitionwhich specifies the type of makefile targets it can support. Thisdefinition appears in configure/os/CONFIG.Common. orconfigure/os/CONFIG.. files.
In a Makefile it is possible to limit the systems for which a particularPROD, TESTPROD, LIBRARY, SCRIPTS, and OBJS is built. For example thefollowing Makefile lines specify that product aaa should be created forsystems that support Host type builds. Product bbb should be created forsystems that support Ioc type builds. Product ccc should be created forall target systems.
A Makefile in this type of directory must define where isrelative to this directory, include /configure files, and specifythe subdirectories in the desired order of make execution. Runninggnumake in a directory with the following Makefile lines will causegnumake to be executed in first and then . The buildrules do not allow a Makefile to specify both subdirectories andcomponents to be built.
A Makefile in this type of directory must define where isrelative to this directory, include configure files, and specifythe target component definitions. Optionally it may contain user definedrules. Running gnumake in a directory with this type of Makefile willcause gnumake to create an O. subdirectory and then executegnumake to build the defined components in this subdirectory. Itcontains the following lines:
For each Host type target architecture, create an executable namedcatest from the catest1.c and catest2.c source files linking with theexisting EPICS base ca and Com libraries, and then install the catestexecutable into the $(INSTALL_LOCATION)/bin/ directory.
EPICS provides an extensive set of make rules. These rules only workwith the GNU version of make, gnumake, which is supplied by the FreeSoftware Foundation. Thus, on most Unix systems, the native make willnot work. On some systems, e.g. Linux, GNU make may be the default. Thismanual always uses gnumake in the examples.
This can be used to save disk space by deleting the O.directories that gnumake will create, but does not remove any installedfiles from the bin, db, dbd etc. directories. gnumake clean.can be invoked to clean a single architecture.
All product, test product, and library source files which appear in oneof the source file definitions (e.g. SRCS, PROD_SRCS,LIB_SRCS, _SRCS) will have their header filedependencies automatically generated and included as part of theMakefile.
Normally all product, test product, and library source files reside inthe same directory as the Makefile. OS specific source files are allowedand should reside in subdirectories os/ or os/posix oros/default.
The epics base config files assume posix source code and define POSIX tobe YES as the default. Individual Makefiles can override this by settingPOSIX to NO. Source code files may have the suffix .c, .cc, .cpp, or .C.
to the Makefile. The following Makefile will create a bptTypeJdegC.dbdfile from an existing bptTypeJdegC.data file using the EPICS baseutility program makeBpt and install the new dbd file into the$(INSTALL_LOCATION)/dbd directory.
A Record.h header file will be created from an existingRecord.dbd file using the EPICS base utility programdbToRecordTypeH. This header will be installed into the$(INSTALL_LOCATION)/include directory and the dbd file will beinstalled into the $(INSTALL_LOCATION)/dbd directory.
Database definition include files named Include.dbd containingincludes for other database definition files can be expanded by theEPICS base utility program dbExpand into a created .dbd file andthe .dbd file installed into $(INSTALL_LOCATION)/dbd. Thefollowing variables control the process:
b1e95dc632