EPICS: 入出力コントローラアプリケーション

デ ベロッパズガイドリリース 3.14.2

2003521

Martin R. Kraimer, Janet Anderson, Andrew Johnson, Eric Norum(ア ルゴンヌ国立研究所)

Jeff Hill(ロスアラモス国立研究所)

Ralph Lange(BESSY)

目 次

1章:はじめに

1.1 概要

本文書はEPICSの主要なコンポーネントの 一つである入出力コントローラ(IOC)に使用するコアソフトウェ アを説明します。EPICS IOCデータベースを開発し、新しいレコード/デバイス/ドライバのサポートを行う 開発者を対象にしています。

本書は、以下のように構成 されています。

Getting Started
EPICSサポートとIOCアプリケーションの作成方法に関する説明。
EPICS概要
EPICSの概要を紹介し、IOCソフトウェアのEPICSの中における役割を示します。
EPICSの ビルド機能
Janet Andersonが執筆したこの章では、ディレクトリ構造、環境およびシステム要件、設定ファイル、Makefilesおよび関連するビルドツールを含むEPICSの【ビルド機能/構築機能】について説明します。
データベースロック機能、スキャン機能およ び処理機能
3つの相互に関連したIOCの機能について説明します。これらの機能はEPICS-IOCの心臓部を構成します。

データベース定義

この章では、IOCデータベースを記述するファイルフォーマッ トについて説明します。これはデータベース定義ツールで使用するフォーマットで、IOCにデータベースをロードするときにも使用さ れます。

IOCの初期化

IOCの初期化には、多くの処理が行われます。こ の章では、初期化に関する問題を解き明かします。

アクセスセキュリティ

IOCには、チャネルアクセスセキュリティが実装 されています。この章では、設定方法と実行方法について説明しています。

IOCのテスト機能

EPICSにはEPICS経由またはvxWorksのシェル経由で実行されるテストルーチンが 付属しています。

IOCのエラーログ記録

IOCコードはシステム全体をカバーするエラーロ ガーにメッセージを送信するルーチンを呼び出すことができます。

レコードサポート

レコードサポートについて説明します。この情報はカスタマイズしたレコードとデバイスサポートを【行う/開発する】場合に必要です。

デバイスサポート

org.page#-8

デ バイスサポートについて説明します。デバイスサポートは、レコードサポートのハードウェア固有の詳細を管理します。つまりこれはハードウェアとレコードサ ポートのインタフェイスとなります。デバイスサポートはハードウェアに直接アクセスし、またはドライバサポートへのインタフェイスとなります。

ドライバサポート

ドライバサポートについて説明します。ドライバは、必ずしも必要ではありませんが、レコードに関する知識はな く、単にハードウェアとの通信を管理します。デバイスサポートのみを使うのではなくドライバサポートを用意すべきときのガイドラインを示します。

静的データベースアクセス

ホストとIOCの両方で実行されるライブラリです。IOCでは、初期化されたEPICSデータベースまたは初期化されていないEPICSデータベースで実行されます。

ランタイムデータベースアクセス

IOCソフトウェアの心臓部はメモリ常駐データ ベースです。この章では、このデータベースに対するインタフェイスを説明します。

デバイスサポートライブラリ

デバイスサポートモジュールには、VMEアドレス空間のような共有リソースを使用す るためのルーチンが用意されています。

EPICS汎用タスク

汎用コールバックタスクとタスクウォッチドッグのタスクがあります。

データベーススキャン機能

レコードの処理を要求するタスクすなわちデータベーススキャンタスクです。

IOCシェル

EPICS IOCシェルはvxWorksシェルの機能のサブセットを提供する簡素な コマンドインタプリタです。

libCom

EPICSベースには、サブディレクトリsrc/libComがあり、ベースの他のコンポーネントが使用 するc言語とc++言語のライブラリが収められています。この 章では、このライブラリについて説明します。

libCom OSI

この章には、EPICSベースが使用するオペレーティングシステム 非依存(OSI)インタフェイスを提供するlibComのライブラリを説明します。LiComにはOSIインタフェイスを実装するオペレーティング システム依存のコードも含まれています。

レジストリ

vxWorksでは、osiFindGlobalSymbolを 使用して、レコード、デバイスおよびドライバサポートを動的にバインドできます。システムによっては、これは常にエラーを返すため、バインドを実装するた めにレジストリ機能が準備されています。グローバルにアクセス可能な記憶装置は、アクセスされる前に登録する必要があるという考えに基づいています。

データベース構造

内部データベース構造を説明します。

概要の章を除き、本文書ではIOCのコアソフトウェアのみについて説明しま す。したがって、シーケンサのようなIOCで実行されるその他のEPICSツールについての説明は除かれています。 チャネルアクセスに関する説明もありません。

本取扱説明書の読者は、次の文書もご参照ください。

Philip StanleyJanet Anderson and Marty KraimerEPICSレコードリファレンスマニュアル

最新バージョンについては、LANLWebサイトをご参照ください。

org.page#-9

EPICS IOCソフトウェア設定管理、Marty Kraimer, Andrew Johnson, Janet Anderson, Ralph Lange

http://www.aps.anl.gov/asd/controls/epics/EpicsDocumentation/AppDevManuals/iocScm-3.13.2/index.html

vxWorksプログラマズガイド、ウィンドリバーシステ ムズ

vxWorksリファレンスマニュアル、ウィンドリバーシ ステムズ

RTEMS Cユーザズガイド、オンラインアプリケーションリサーチ

1.2 謝辞

IOCの基本機能と動作方法の基本モデルは、LANL/GTABob Dalesioにより開発されました。チャネルアクセスの基本的な方針は、LANL/GTAJeff Hillにより開発されました。BobJeffIOCソフトウェアの原型の主要な実装者です。こ のソフトウェア(GTACS)は、LANL/GTAユーザからのフィードバックを得て、数年間 かけて開発されました。この構想なしにはEPICSは誕生しませんでした。

1990年から1991年にかけて、レコードとデバイスのサポート を容易に拡張できる機能を目標に、ANL/APSIOCソフトウェアを大幅に改訂しました。Marty Kraimer(ANL/APS)は、拡張可能なレコードとデバイスのサポー トに必要なデータ構造を設計し、IOC常駐ソフトウェアに必要な変更を行う責任者 でした。Bob Zieman(ANL/APS)UNIXビルドツールと新しい機能をサポートするの に必要なIOCモジュールを設計、実装しました。Frank Lenkszus(ANL/APS)は新しい機能をサポートするのに必要なデー タベース設定ツール(DCT)に対する大幅な変更を行いました。Janet AndersonIOCソフトウェアの各種の機能をシステマチック にテストする方法を開発し、レコードサポートの変更の主要な実装者です。

1993年から1994年に、LANLMatt Needsは、高速データベースリンクとデータベース・デバッグ・ツールを実装して提供しました。

1993年から1994年に、ANL/APSJim KowalkowskiGDCTを開発し、標準フォーマットとして使用され ているアスキ・データベースインスタンスを開発しました。そのときに、dbLoadRecordsdbLoadTemplateを作成しました。

buildユーティリティメソッドにより、IOCにロードされるUNIXのバイナリファイルが生成されるようになり ました。新しいIOCアーキテクチャがサポートされるようにな り、これが問題を生じました。1995年に、実用化されなかったEpicssRXの開発から多くを学び、ビルドユーティリ ティとバイナリファイル(default.dctsdr)はすべてアスキファイルで置き換えられるこ とになりました。新方式によりアーキテクチャに独立でよりフレキシブルなレコード/デバイス/ドライバのサポート環境が実現されました。Marty KraimerJohn WinansJeff Hillの考えをもとに、主に実装を行いました。Bob Dalesioは、1)既存のアプリケーションのアップグレードを 困難にし、2)性能を劣化させることのないように、管理し ました。

1996年の初めに、Bob Dalesioはランタイムリンク変更を行う課題に取り組みました。これはBobMarty Kraimerとの共同作業に発展しました。これにはデータベースにチャネルアクセスリンクを行う新しいコード、ロックセット のための新しいライブラリおよびデータベースリンクにアクセスするためのクリーナインタフェイスが含まれます。

1999年の初めに、非vxWorksオペレーティングシステムへのiocCoreポートが開始されました。主要な開発者は、Marty KraimerJeff HillおよびJanet Andersonでした。William Luptonはシーケンサを変換するとともに、osiSemosiThreadposixスレッド実装を支援しました。Eric NorumRTEMSにポートを提供し、非vxWorks環境で使用するシェルの開発に貢献しまし た。Ralph LangeHPUXにポートを提供しました。

その他多くの人が、EPICSの開発に協力し、新しいレコード、デバイス およびドライバサポートモジュールが開発されました。

org.page#-10

org.page#-11

2章:Getting Started

2.1 はじめに

この章には、EPICS IOCアプリケーションを作成するために必要な事項を簡単に紹介しています。次の項目があります。

IOCアプリケーションの例を作成、ビルドおよび 実行するための説明

・チャネルアクセスクライアントの例を作成、ビルドおよび実行するための説明

baseが提供するコマンドシェルであるiocshに関する簡単な説明

IOCコンポーネントをビルドするルールの説明

・アプリケーションをビルドするためのファイルを生成するperlスクリプトであるmakeBaseApp.plの説明

vxWorksブートパラメータに関する簡単な検討

レコード/デバイス/ドライバのサポートなどIOCの基本機能に慣れ、iocデータベース作成の経験がない場合、この章 を理解することは困難かもしれません。この経験があれば、この章によりアプリケーションをビルドするために必要なほとんどの内容が理解できます。

2.2 IOCアプリケーションの例

こ の節では、ディレクトリ<top>myexampleAppというIOCアプリケーション例とiocmyexampleというiocディレクトリを作成する方法について説明していま す。

2.2.1 EPICS_HOST_ARCHが定義されていることを確認

コマンド

echo $EPICS_HOST_ARCH (Unix/linux)

または

set EPICS_HOST_ARCH (Windows)

を実行します。

こ れにより、ワークステーションのアーキテクチャが、たとえばlinux-x86win32-x86のように表示されます。”未定 義の変数”エラーが発生した場合、EPICS_HOST_ARCHを、たとえばsolaris-sparcのように、ホストオペレーティングシステム名に、ハ イフォンに続けてホストアーキテクチャをつないだ文字列に設定します。【ベース\/起動/base\/startup】ディレクトリのperlスクリプトEpicsHostArch.plEPICS_HOST_ARCHを設定するために準備されています。

2.2.2 アプリケーション例の作成

次のコマンドにより、アプリケーション例が作成されます。

mkdir <top>

cd <top>

org.page#-12

<base>/bin/<arch>/makeBaseApp.pl -t example myexample

<base>/bin/<arch>/makeBaseApp.pl -i -t example myexample

最後のコマンドは、IOCのアーキテクチャの入力を要求します。これ によりベースがビルドされたアーキテクチャの一覧が表示されます。

<base>へのフルパスが使われなければなりません。 たとえば、次のとおりです。

/home/phoebus/MRK/epics/base/bin/linux-x86/makeBaseApp.pl ...

ウィンドウズユーザへの注意:Perlスクリプトはwin95/NTのコマンドperl<scriptname>を使って呼び出されます。たとえば、WIN95/NTでアプリケーションを作成する場合、次のよ うになります。

perl C:\epics\base\bin\win32-x86\makeBaseApp.pl -t example myexample

2.2.3 ファイルの検査

<top>の下に現れるファイルを確認してください。 これはビルドする前に行ってください。これにより、作成されたファイルを参照しなくても、アプリケーションをビルドするために必要な代表的なファイルを確 認できます。

2.2.4 シーケンサの例

シーケンサは、バンドルされていない【製品/プロダクト】としてサポートされています。 この例には、状態表示プログラムの例であるsncExample.sttが含まれます。makeBaseAppにより作成された【ため、/だけでは】この例はビルドされることや実行 されることはありません。

sncExample.stをビルドできるようになる前に、シーケンサ を例で使用しているベースと同じバージョンのベースを使ってビルドする必要があります。

sncExampleをビルドするためには、次のファイルを編集 します。

configure/RELEASE - SNCSEQをシーケンサの位置に設定します。

myexampleApp/src/Makefile 次の行からコメント文字を削除します

myexample_SRCS += sncExample.stt

myexample_LIBS += seq pv

iocBoot/iocmyexample - st.cmdにはシーケンスプログラムを起動するコマンドがあり ます

#seq sncExample,"user=<user"

行の先頭のコマンド文字を削除します。

Makefileにはスタンドアロンアプリケーション、すな わちEPICSデータベースを使わないアプリケーションと してsncExampleをビルドする方法についても説明されていま す。

2.2.5 ビルド

ディレクトリ<top>で次のコマンドを実行します。

make

注:GNU makeがデフォルトでないシステムでは、gnumake,gmakeなどのコマンドが必要です。

2.26 ファイルの検査

ここでは作成されたファイルと元のファイルが表示されます。

2.2.7 ioc例の実行

この例はvxWorksRTEMSまたはサポートしているホスト上で実行でき ます。

linuxsolarisのようなホストでは

cd <top>/iocBoot/iocmyexample

../../bin/linux-x86/myexample st.cmd

vxWorks-ブートパラメータをこの章の最後に示された 値に設定し、iocを再起動します。

RTEMS-RTEMSは起動スクリプトと設定ファイルの読み込み にTFTPを使います。TFTPサーバで、次の操作を行います。

・ すべてのdb/xxxファイルを<tftpbase>/epics/<target_hostname>/db/xxxにコピーします。

・ すべてのdbd/xxxファイルを<tftpbase>/epics/<target_hostname>/dbd/xxxにコピーします。

iocBoot/iocmyexample/st.cmd<tftpbase>/epics/<target_hostname>/st.cmdにコピーします。

・アプリケーションの実行可能イメージをターゲットマシンに転送し、起動します。これを行うための方法は、ター ゲットハードウェアに依存します。代表的な方法には、BOOTP/TFTP、フロッピディスクからの起動、フラッシュ メモリにアプリケーションを保存することまたはgdbを使ってダウンロードしてアプリケーション を実行することがあります。

iocが起動した後、”IOCテスト機能”に説明されたシェ ルコマンド(dblまたはdbpr <recordname>)を試行します。レコードの一覧を表示するには、dblを実行します。

ヘルプ機能も使用できます。次のように入力します。

help

help <cmd>

こ こで、cmdhelpにより表示されたコマンドの一つです。

vxWorksでは、ヘルプ機能は次のように入力した後に 使用できます。

iocsh

2.3 チャネルアクセスホストの例

ホストの例は次の操作により作成できます。

cd <mytop>

<base>/bin/<arch>/makeBaseApp.pl -t caClient caClient

make

二つのチャネルアクセスの例があります。

caExample-この例ではpvnameiをコマンド引数として受け取り、接続し、pvnameの現在の値を読み取り、結果を表示して終了します。 この例は次のように入力するだけで実行されます。

<mytop>/bin/<hostarch>/caExample <pvname>

ここで、

<mytop>は、アプリケーションのトップディレクトリまでのフ ルパス名です。

<hostarch>は、ホストのアーキテクチャです。

<pvname>は、dbl iocシェルコマンドにより表示されるレコード名の一つで す。

caMonitor-この例では、pvnameが各行に記述された一覧を含むファイル名を コマンド引数として受け取ります。それぞれのpvに接続し、モニタリクエストを送信します。 すべてのチャネルアクセスイベント、接続イベントなどに対してメッセージを表示します。

org.page#-14

2.4 iocsh

vxWorksのシェルはvxWorksだけが使用できるため、EPICSベースにはiocshが準備されています。メインプログラムで は、次のように呼び出されます。

iocsh("filename")

または

iocsh(0)

引数がファイル名であれば、ファイルのコマンドは実行され、iocsh【を返します/のプロンプトに戻ります】。引数が0の場合、ioschexitコマンドを実行するまで、プロンプトに対し て入力されたコマンドを実行する対話モードに移行します。

こ のシェルについては、233ページの第19章”IOCシェル”に詳細が説明されてい ます。

vxWorksでは、iocshは自動的には起動しません。vxWorksシェルに次のコマンドを与えることにより起 動します。

iocsh

vxWorksシェルに戻るには、次のように入力します。

exit

2.5 IOCコンポーネントのビルド

ビ ルドのルールの詳細は”Epicsのビルド機能”の章に示されて います。この節では、IOCアプリケーションに必要なほとんどのコンポーネント のビルド方法を説明します。makeBaseAppにより生成されたmyexampleApp/src/Makefileからの抜粋を使用します。

次の2種類のアプリケーションをビルドできます。

・サポートアプリケーション

iocアプリケーションが使用するアプリケーショ ン(コマンド)です。ここに示すルールにより、<top>の直下に作成される以下のディレクトリのい ずれかにインストールされます。

include
C
言語のincludeファイルはここにインストールされます。アプリケー ションが作成するヘッダファイルまたはxxxRecord.dbdxxxMenu.dbdファイルから生成されるヘッダファイルのいずれかで す。

dbd

各 ファイルには、includerecordtypedevicedriverおよびregistrarデータベース定義コマンドを組み合わせたものが格納 されます。次にあげるファイルがインストールされます。

xxxRecord.dbdxxxMenu.dbdファイル

・任意のxxx.dbdファイル

iocアプリケーションはファイルyyyInclude.dbdから生成されたファイルyyy.dbdがインストールされます。

dbレコードインスタンス定義を含むファイルがインス トールされます。

lib/<arch>すべてのソースモジュールはコンパイルされ、【供給/共有】ライブラリまたは静的ライブラリに保存されま す(win32/では】dll)

IOC applications

実際のIOCにロードされるアプリケーションがインス トールされます。

org.page#-15

2.5.1 IOCコンポーネントへのバインド

多くのIOCコンポーネントはiocの初期化中にバインドされるため、共有ライ ブラリまたは静的ライブラリまたはその両方へのリンク方法が準備されています。IOCに使われる方法は、xxxInclude.dbdファイルから、適切なライブラリモジュール を強制的に参照するC++言語のプログラムを生成します。これを行う ために、データベース定義に関する次のキーワードが使われます。

recordtype

device

driver

registrar

この方法には、IOCコンポーネントがepicsExport機能を呼び出すことが要求されます。このよ うなコンポーネントのそれぞれには、次の宣言文が含まれる必要があります。

#include
<epicsExport.h>

各 レコードサポートモジュールには、次の宣言文が含まれる必要があります。

epicsExportAddress(rset,xxxRSET);

各 デバイスサポートモジュールには、次の宣言文が含まれる必要があります。

epicsExportAddress(dset,devXxxSoft);

各 ドライバサポートモジュールには、次の宣言文が含まれる必要があります。

epicsExportAddress(drvet,drvGpib);

キー ワードregistrarにより、epicsコンポーネントは次のプロトタイプを有するC言語関数を供給することが有効になります。

typedef void (*REGISTRAR)(void);

こ の関数は、”レジストリ”の章で説明する事項を登録します。myexampleAppにより、サブルーチンレコードの関数を設定する例が 与えられます。次の宣言文が含まれます。

static
registryFunctionRef mySubRef[] = {
{"mySubInit",(REGISTRYFUNCTION)mySubInit},
{"mySubProcess",(REGISTRYFUNCTION)mySubProcess}
};

static void mySub(void){
registryFunctionRefAdd(mySubRef,NELEMENTS(mySubRef));

}
epicsExportRegistrar(mySub);

epicsExportRegistrariocshコマンドを登録するためにも使用されます。

:システムには、エクスポートしたものと同じソースモ ジュールにepicsExportAddressまたはepicsExportRegistrar宣言文が存在することが要求されます。

2.5.2 Makefileのルール

2.5.2.1 サポートアプリケーションのビルド

#xxxRecord.hxxxRecord.dbdから作成されます。
DBDINC+= xxxRecord
DBD+= myexampleSupport.dbd
org.page#-16
LIBRARY_IOC+= myexampleSupport
myexampleSupport_SRCS+= xxxRecord.c
myexampleSupport_SRCS+= devXxxSoft.c
myexampleSupport_SRCS+= dbSubExample.c
myexampleSupport_LIBS+= $(EPICS_BASE_IOC_LIBS)
DBDINCルールは、ファイルxxxRecord.dbdを参照します。このファイルから、ファイルxxxRecord.hが作成され、<top>/includeに保存されます

DBDルールは、sourceディレクトリからmyexampleSupport.dbdを検索し、<top>/dbdにインストールします

LIBRARY_IOC宣言文は、共有ライブラリ/静的ライブラリを作成し、<top>/lib/<arch>にインストールします。

myexampleSupport_SRCS宣言文は、コンパイルされるすべてのソースファイル に名前を付け、ライブラリに保存します。

上記の宣言文は、多くのサポートアプリケーションをビルドするために必要となるすべての宣言文です。

2.5.2.2 IOCアプリケーションのビルド

次の宣言文によりIOCアプリケーションをビルドします。

PROD_IOC = myexample

DBD += myexample.dbd

# <name>_registerRecordDeviceDriver.cpp<name>.dbdから生成される。

myexample_SRCS += myexample_registerRecordDeviceDriver.cpp

myexample_SRCS_DEFAULT += myexampleMain.cpp

myexample_SRCS_vxWorks += -nil-

#The following adds support from base/src/vxWorks

#次の行はbase/src/vxWorksからのサポートライブラリを追加します。

myexample_OBJS_vxWorks += $(EPICS_BASE_BIN)/vxComLibrary

myexample_LIBS += myexampleSupport

myexample_LIBS += $(EPICS_BASE_IOC_LIBS)

PROD_IOCiocアプリケーションにmyexampleという名前を付けます。

DBDコマンドがsourceディレクトリにファイルmyexampleInclude.dbdがあることを確認すると、それがdbExpandを呼び出し、myexampleInclude.dbdを読み込み、ファイルmyexample.dbdを作成し、<top>/dbdにインストールします。

宣 言文myexample_SRCSの数には、制限がありません。

myexample_registerRecordDeviceDriver.cpp1つだけであることの方が特殊な場合です。この場合、 次のようになります。

perlスクリプトregisterRecordDeviceDriver.plが実行されます。myexample.dbdが入力され、 myexample_registerRecordDeviceDriver.cppが生成されます。

2.6 makeBaseApp

makeBaseAppは、アプリケーション領域を作成するperlスクリプトです。次のディレクトリが作成さ れます。

<top>/Makefile

<top>/configureこのディレクトリにはEPICSビルドシステムが使用するファイルが含まれます。

<top>/xxxApp -ほとんどのサブモジュールのディレクトリと関連する ファイルのセット。

org.page#-17

<top>/iocBoot サブディレクトリと関連するファイルがインストール されます。

<top>/iocBoot/iocxxx -サブディレクトリと単一のiocのためのファイルがインストールされます。

makeBaseAppはディレクトリを作成し、作成されたディレ クトリ内にテンプレートファイルをコピーし、テンプレートファイル内でマクロを展開します。EPICSベースには、simpleexample2種類のテンプレートがあります。これは単純 なアプリケーションであることを意味します。【サイトでは/各サイト毎に】、追加機能を提供する専用の テンプレートファイルを作成することができます。この節では、makeBaseAppの機能について説明し、次の節ではsimpleテンプレートとexampleテンプレートの詳細について説明します。

2.6.1 使用方法

makeBaseAppには、4種類の形態のコマンドラインがあります。

<base>/bin/<arch>/makeBaseApp.pl -h

ヘルプを表示します。

<base>/bin/<arch>/makeBaseApp.pl -l [options]

使用可能なアプリケーションテンプレートを一覧表示します。これを実行することにより、現在のディレクトリを変 更することはありません。

<base>/bin/<arch>/makeBaseApp.pl [-t type] [options] app ...

アプリケーションディレクトリを作成します。

<base>/bin/<arch>/makeBaseApp.pl -i -t type [options] ioc ...

iocの起動ディレクトリを作成します。

すべてのコマンドのオプションは次のとおりです。

-a arch

-iを付加することによりIOCアーキテクチャを設定します(たとえば、vxWorks-68040)archを指定していない場合、メッセージが表示さ れます。

-b base

EPICSベースのフルパスを表示します。指定してい ない場合、config/RELEASEEPICS_BASEエントリの値が使われます。configディレクトリが存在しない場合、makeBaseAppを呼び出すのに使ったコマンドラインから取 得します。

-T template

テンプレートのtopディレクトリを設定します(アプリケーションのテンプレートが格納され ています)。指定していない場合、テンプレートパスはconfig/RELEASETEMPLATE_TOPエントリの値が使われます。configディレクトリが存在しない場合、環境変数EPICS_MBA_TEMPLATE_TOPから取得するか、設定されない場合EPICSベースのテンプレートが使用されます。

-d

メッセージ出力(デバックに使用)

makeBaseApp.pl [-t type] [options] app ...で専用に使われる引数

app

1つ以上のアプリケーション名(作成されるディレクトリにはこの名前に& rdquo;App”が追加されます)

-t type

テ ンプレートの種類を設定します(-lを使うと、有効なテンプレートの種類の一覧が表示さ れます)。このオプションを使わない場合、環境変数EPICS_MBA_DEF_APP_TYPEから取得するか、設定されない場合& rdquo;default”を、次に”example”を試行します

makeBaseApp.pl -i [options] ioc ...

で専用に使われる引数

ioc

1つ以上のIOC(作成されるディレクトリは、この名前の前に ”ioc”が付加されます)-a<arch>によりIOCアーキテクチャを設定します(たとえば、mv167)。してしない場合、この情報を追加するためのメッ セージが表示されます。これは-iオプションとともに使われる場合に限り有効です。

org.page#-18

2.6.2 環境変数

EPICS_MBA_DEF_APP_TYPE

デフォルトとして使用するアプリケーションの種類

EPICS_MBA_TEMPLATE_TOP

テンプレートのtopディレクトリ

2.6.3 記法

新しい<top>を作成するためには、次のコマンドを実行し ます。

mkdir <top>

cd <top>

<base>/bin/<arch>/makeBaseApp.pl -t <type> <app> ...

<base>/bin/<arch>/makeBaseApp.pl -i -t <type> <ioc> ...


makeBaseAppは次の作業を実行します。

EPIC_BASEのインストール場所は次の順で決定されます

-bオプションが設定されている場合、これが使 用されます。

<top>/config/RELEASEファイルがあり、EPIC_BASEの値が定義されている場合、これが使用され ます。

makeBaseAppの実行コマンド名から取得します。これを行 うためには、使用しているリリースのEPICSベースのmakeBaseApp.plスクリプトへのフルパス名を与える必要があ ります。

TEMPLATE_TOPのインストール場所も同様の方法で決定され ます

-tオプションが設定されている場合、これが使 用されます。

<top>/config/RELEASEファイルがあり、TEMPLATE_TOPの値が定義されている場合、これが使用され ます。

EPICS_MBA_TEMPLATE_TOPが定義されている場合、これが使用されま す。

<epics_base>/templates/makeBaseApp/topに設定します。

-lが指定されている場合、アプリケーションの 種類が一覧表示され、makeBaseAppは終了します。

-iが指定され、-aが指定されていない場合、IOCアーキテクチャを入力するためのメッセージ が表示されます。

・アプリケーションの種類は、次の手順で決定されます。

-tが指定されている場合、これを使用します。

EPICS_MBA_DEF_APP_TYPEが定義されている場合、これを使用します。

・ テンプレートdefaultAppがある場合、アプリケーションの種類はdefaultと同じに設定されます。

・ テンプレートexampleAppがある場合、アプリケーションの種類はexampleと同じに設定されます。

・アプリケーションの種類がTEMPLATE_TOPで指定されていない場合、makeBaseAppはエラーメッセージを表示して終了します。

Makefileが存在しない場合、作成されます。

・ ディレクトリconfigureが存在しない場合、作成されすべてのconfigureファイルを作成します。

-iが指定されている場合、次のとおりです。

・ ディレクトリiocBootが存在しない場合、ディレクトリが作成され、テンプ レート起動ディレクトリのファイルがコピーされます。

・ コマンドラインで指定された<ioc>に対して、ディレクトリiocBoot/ioc<ioc>が作成され、テンプレートのファイルが格納されます(ReplaceLine()タグを変更、以下を参照)

-iが指定されていない場合、次のとおりです。

・ コマンドラインで指定された<app>それぞれに対して、ディレクトリ<app>Appが作成され、テンプレートのファイルが格納されます(ReplaceLine()タグを変更、以下を参照)


org.page#-19

2.6.4 テンプレート内でのタグ変更

テンプレートから新しいアプリケーションにファイルをコピーしたとき、makeBaseAppはその時点で値が既知のファイルの名前やテ キストに組み込まれている定義済みのタグを変更します。アプリケーションテンプレートはこの機能を次のように展開します。

makeBaseApp内に2つのperlサブルーチンが定義されています

ReplaceFilename-テンプレートのファイル名の次の文字列をコ マンドラインに指定されたアプリケーション名やアプリケーションタイプに変更します。

_APPNAME_

_APPTYPE_

ReplaceLine-テンプレートのファイルの各行で次の文字列 を置き換えます。

_USER_

_EPICS_BASE_

_ARCH_

_APPNAME_

_APPTYPE_

_TEMPLATE_TOP_

_IOC_

application typeディレクトリにReplace.plという名前のファイルが格納されている場合、次の処 理を行います。

・上記のサブルーチンの一方または両方を専用バージョンのサブルーチンに変更

ReplaceFilenameの終了時に呼び出されるサブルーチンReplaceFilenameHook($file)

を追加

ReplaceLineの終了時に呼び出されるサブルーチンReplaceLineHook($line)

を追加

・コマンドラインオプションが実行された後に実行される他のコードを追加


2.6.5 ベースに付属しているmakeBaseAppテンプレート

2.6.5.1 サポート

サポートアプリケーションをビルドするのに必要なファイルを作成します。

2.6.5.2 ioc

-iオプションがない場合iocアプリケーションをビルドするのに必要な ファイルを作成し、-iオプションがある場合ioc起動ディレクトリを作成します。

2.6.5.3 (example)

-iオプションがない場合、【例/example アプリケーション】例を実行するファイルを作成しま す。サポートとiocアプリケーションの両方がビルドされます。-iオプションがある場合、【例/example アプリケーション】例を実行するのに使用するioc起動ディレクトリを作成します。

2.6.5.4 caClient

2つのチャネルアクセスクライアントをビルド します。

2.6.5.5 caServer

ポータブルアクセスサーバの例をビルドします。


org.page#-20

2.7 vxWorks起動パラメータ

vxWorks起動パラメータは、IOCのコンソールシリアルポートを経由して設定 できます。ワークステーションのウィンドウにシリアルポートを接続する方法がわかれば、簡単に使用できます。

vxWorks起動パラメータは、次のように表示されま す。


boot device : xxx

processor number : 0

host name : xxx

file name : <full path to board support>/vxWorks

inet on ethernet (e) : xxx.xxx.xxx.xxx:<netmask>

host inet (h) : xxx.xxx.xxx.xxx

user (u) : xxx

ftp password (pw) : xxx

flags (f) : 0x0

target name (tn) : <hostname for this inet address>

startup script (s) : <top>/iocBoot/iocmyexample/st.cmd


各フィールドの実際の値は、サイトとIOCに依存します。変更可能な箇所は、vxWorks起動イメージと起動スクリプトの場所です。

適切なボードサポート起動イメージのフルパス名を指定する必要があります。bootpを使用する場合、bootpホストの設定データベースに同じ情報を加え る必要があります。

起動パラメータを適切に設定し、IOCのリセットボタンを押すか、@コマンドを使うと起動が【開始します/始まります】。ワークステーションのスク ロールウィンドウに【付属し/IOCのコンソールポートを【使用すると/接続すると】非常に便利であることがお分か りになるはずです。


org.page#-21

3章:EPICSの概要

3.1 EPICSとは

EPICSはソフトウェアコンポーネントとツールで構 成され、アプリケーション開発者が制御システムを作成するのに使用します。基本的なコンポーネントは以下のとおりです。

OPI:オペレータインタフェイス。各種のEPICSツールを実行するワークステーションです。

IOC:入出力コントローラ。EPICSランタイムデータベースと【/この】取扱説明書に示したソフトウェアコンポーネン トを統合してサポートする任意のプラットフォームです。一例としてワークステーションがあります。その他の例として、【/リアルタイムオペレーティングシステムとして】vxWorks/またはRTEMS】を使ったVME/VXIベースシステム【またはリアルタイムオペレーティン グシステムとしてRTEMS/】があります。

LAN:ローカルエリアネットワーク。IOCOPIが通信する通信ネットワークです。EPICSにはチャネルアクセスというソフトウェアコ ンポーネントがあり、チャネルアクセスクライアントと任意の数のチャネルアクセスサーバ間で、ネットワーク透過【/な】通信が可能です。


EPICSにより構築される制御システムは、次のよう な物理的構成になっています。

EPICS Basic structure


この章のこれ以降の部分では、EPICSの概要を説明します。

・基本属性:EPICSの基本的な属性。

・プラットフォーム:EPICSがサポートするベンダが供給するハードウェ アとソフトウェアプラットフォーム。

IOCソフトウェア:EPICSが提供するIOCソフトウェアコンポーネント。

・チャネルアクセス:IOCデータベースへのネットワーク非依存アクセ スをサポートするEPICSソフトウェア。

OPIツール:EPICSが提供するOPIベースツール。

EPICSコア:EPICSのコアソフトウェアの一覧、このソフトウェ アなしではEPICSが正しく作動しません


3.2 基本属性

EPICSの基本属性は、次のとおりです。


org.page#-22

・ツールベース:EPICSは制御システムを作成するための多数のツー ルを提供します。これにより、専用コードの開発を最小限にし、同一のオペレータインタフェイスを実現します。

・分散:任意の数のIOCおよびOPIをサポートできます。ネットワークが飽和し ていない状態では、ボトルネックは存在しません。システムの規模の変更に自然に対応できる分散システムです。1台のIOCが飽和した場合、この機能は複数のIOCに分散されます。1台のホストがすべてのアプリケーションを実 行する代わりに、アプリケーションは複数のOPIに分散して実行されます。

・ イベントドリブン:EPICSソフトウェアコンポーネントは可能な限りイベントド リブンにより作動する様に設計されています。たとえば、変化の検出のためにIOCをポーリングするのではなく、チャネルアクセスクラ イアントは変更発生の通知iiを要求します。この方式により、リソースを有効利用し、応答時間も短縮されます。

・高性能:SPARCワークステーションはチャネルアクセスイベ ントにより、毎秒数千の画面更新を処理できます。68040 IOCは、チャネルアクセスイベントの生成を含む毎秒6000を超えるレコード処理を実行できます。


3.3 ハードウェア-ソフトウェアプラットフォーム(ベンダ供給)

EPICSのコアコンポーネント(IOCコンポーネントを含む)は多様なシステムで実行できます。現在これ には次のようなプラットフォームがありますが、ソケットとスレッドをサポートするものであれば、新しいオペレーティングシステムプラットフォームを容易に サポート【します/できます】。現在、ほとんどの32ビットプロセッサをサポートしています。64ビットプロセッサについては試験中です。


3.3.1 OPI

プラットフォーム

Unixベースのワークステーション:SOLARISHP-UXを含むプラットフォームをサポート

Linux

DarwinMac OS 10

Windows NT

VMSの限定したサポート


3.3.2 LAN

ハードウェア

・イーサネット(ほとんどの種別)

ソフトウェア

・ソケット経由のTCP/IPプロトコル


3.3.3 IOC

ハードウェア

VME/VXIバスと周辺機器

・各種のVMEモジュール(ADコンバータ、DAコンバータ、バイナリI/Oなど)

Allen Bradleyスキャナ(ほとんどのAB I/Oモジュール)

GP-IB機器


org.page#-23

BITBUS機器

CAMAC

CANBUS

・モトローラ68K

・インテル

AMDアスロン

PowerPC

Sun Sparc

HP


ソフトウェア

vxWorksオペレーティングシステム

・リアルタイムカーネル

・ 豊富な”擬似Unix”ライブラリ

RTEMS

Linux

Unix

Darwin

win32


3.4 IOCソフトウェアコンポーネント

IOCには次に示すEPICSが提供するソフトウェアコンポーネントがあ ります。

EPICS software components

IOCデータベース:メモリ常駐データベースと関 係するデータ構造


org.page#-24

・データベースアクセス:データベースアクセスルーチン。レコードとデバイスサポートを例外として、データベー スへのすべてのアクセスはデータベースアクセスルーチンを経由します。

・スキャナ:レコードを処理するときを決定する機構です。

・レコードサポート:レコードタイプには、種類に応じて対応するレコードサポートルーチンがあります。

・デバイスサポート:それぞれのレコードタイプは、1つ以上のデバイスサポートルーチンを使用で きます。

・デバイスドライバ:デバイスドライバは外部のデバイスにアクセスします。ドライバには、対応するドライバ割り 込みルーチンがあります。

・チャネルアクセス:外界とIOCのインタフェイスです。データベースアクセ スに対して、ネットワークに依存しないインタフェイスを提供します。

・モニタ:データベースフィールドの値に変更があったとき、データベースモニタが呼び出されます。

・シーケンサ:有限状態マシンです。


以下に、IOCの主要なコンポーネントとその相互作用につ いて簡単に説明します。


3.4.1 IOCデータベース

IOCの心臓部は、データベースの内容を記述する各種のメ モリ常駐構造を伴うメモリ常駐データベースです。EPICSai(アナログ入力)ao(アナログ出力)などのようなさまざまなレコードタイプをサポートし ます。

それぞれのレコードタ イプには固定されたフィールドがあります。すべてのレコードタイプに共通なフィールドもありますが、特定のレコードタイプ専用のものもあります。レコード にはレコード名が、フィールドにはフィールド名があります。データベースレコードの最初のフィールドにはレコード名が保存され、同じTCP/IPサブネットに接続されたすべてのIOCについて、重複しないことが必要です。

データ構造が規定されているため、データベースに効率的にアクセスできます。多くのソフトウェアコンポーネント では、データベースにはデータベースアクセスルーチンを経由してアクセスするため、この構造を意識することはありません。


3.4.2 データベースアクセス

レ コードとデバイスサポートを例外として、データベースはチャネルまたはデータベースアクセスルーチン経由でアクセスされます。詳細については、193ページの第15章”ランタイムデータベースア クセス”を参照してください。


3.4.3 データベーススキャン機能

データベーススキャン機能は、レコードを処理する時を決定する機構です。定期、イベント、I/Oイベント、受動およびスキャン・ワンスの5種類のスキャン方式を使用できます。

Periodic:レコードを定期的に処理する要求を行いま す。いくつかの定義済みの時間間隔をサポートします。

Event:イベント・スキャンは、IOCソフトウェア・コンポーネントのイベントが 掲示されたときに実行されます。実際のサブルーチン呼び出しは、次のとおりです。

post_event(event_num)

I/O IntrI/Oイベント・スキャンは、外部割り込みが生じ たときに実行されます。外部割り込みを受け入れるには、IOCデバイスドライバ割り込みルーチンが使用可 能であることが必要です。

Passive:受動レコードはリンクされたレコードが処 理されたことまたはチャネルアクセスのような外部変更の結果実行されます。

ScanOnce:キャッシュ保存を行うために、スキャンシステムに は一度だけレコードを処理するルーチンscanOnceが準備されています。


org.page#-25

3.4.4 レコードサポート、デバイスサポートおよびデバイスドライバ

データベースに は、対応するレコード・サポート・モジュールがあるため、レコードタイプ固有の情報は必要ありません。したがって、データベース・アクセスは任意の数と種 類のレコードをサポートできます。同様に、レコードサポートにはデバイス固有の情報はなく、それぞれのレコードタイプに任意の数の独立したデバイス・サ ポート・モジュールを保有できるようにしています。ハードウェアにアクセスする方法がデバイス・サポートにより処理できるものより複雑である場合、デバイ ス・ドライバが使われます。

対応するハードウェアのないレコードタイプには、デバイスサポートやデバイスドライバはありません。

IOCソフトウェアは、データベース・アクセス・レイヤは 呼び出す方法を除きレコード・サポート・レイヤに関する情報が全くないことを前提に作成されています。レコード・サポート・レイヤは呼び出す方法(API)を 除きデバイス・サポート・レイヤに関する情報が全くありません。同様に、デバイス・サポート・レイヤにある唯一の情報は、対応するドライバを呼び出す方法 だけです。この設計により、【レコードタイプ、デバイスタイプおよびドライバを選択し、特別なインストールおよびインストール内に特別なIOCを組み込むことも/特定のインストレーションあるいはインストレーショ ンの中の特定のIOC毎にレコードタイプ、デバイスタイプ、ドライバを選 択したセットを使用することが】可能です。残りのIOCシステムソフトウェアには影響はありません。

ア プリケーション開発者はレコードサポート、デバイスサポートおよびデバイスドライバを開発できるため、これらについては後の章で詳細に【ついて/】説明します。

全 てのレコード・サポート・モジュールには、データベース・スキャナにより呼び出されるレコード処理ルーチンを用意する必要があります。が準備されていま す。レコード処理は、次の機能の組合せで構成されています(レコードタイプによってはすべての機能を必要とする ことはありませんしないこともあります。)

・ 入力:入力読み込み。デバイスサポートルーチンを経由、ハードウェアから、データベースリンク経由で他のデータベースレコードから、またはチャネルアクセ スリンク経由で他のIOCから、入力データを取得します。されます。

・変換:エンジニアリング・ユニットへの入力値の変換またはエンジニアリング・ユニットから出力値への変換を行 います。

・ 出力:出力書き出し。出力は、デバイスサポートルーチンを経由、ハードウェアに、データベースリンク経由で他のデータベースレコードに、またはチャネルア クセスリンク経由で他のIOCに、出力されます。

・ アラーム発生:アラームをチェックまたはしアラームエベントを発生します。

・モニタ:チャネルアクセス・コールバックに関係したモニタをトリガします。

・ リンク:リンクされたレコードのトリガ処理を処理トリガします。


3.4.5 チャネルアクセス

チャネルアクセスについては、次の節で説明します。


3.4.6 データベースモニタ

データベースモ ニタは、データベースの値変更に対してコールバック機能を提供します。これにより呼び出し側は、データベースに連続的にポーリングしなくても、データベー スの値変更を知ることができます。値の変更、アラームの変更またはアーカイブ変更またはそのすべてを指定するために、マスクを設定することができます。

現時点では、チャネルアクセスだけがデータベースモニタを使用しています。他のソフトウェアはデータベースモニ タを使用してはいけません。モニタルーチンは、チャネルアクセスだけに使用されているため、詳細に説明しません。


3.5 チャネルアクセス

チャ ネルアクセスはIOCデータベースに対してネットワーク透過なアクセスを 提供します。これはクライアント/サーバモデルに基づきます。IOCにはチャネルアクセスサーバがあり、任意の数のクラ イアントと通信を確立しようとしています。チャネルアクセスクライアントサービスはOPIIOCのいずれでも使用できます。クライアントは任意の数 のサーバと通信できます。


org.page#-26

3.5.1 クライアントサービス

基本的なチャネルアクセスクライアントサービスは以下のとおりです。

・検索:選択した処理変数をもつIOCの場所を特定し、通信を確立します。

Get:選択した処理変数の値と付加情報を取得し ます。

Put:選択した処理変数の値を変更します。

・ イベント追加:状態変更のコールバックを追加します。関連するプロセス変数の状態が変更されたときに限りサーバが情報を送信することを要求します。値の変 更、アラーム状態および重要性(シビアリティ)またはそのいずれかの変更、アーカイブ値の変更のような状態変化の任意の組合せを要求できます。多くのレ コードタイプには値変化に対するヒステリシス係数があります。


プロセス変数の値を要求することに加え、次の付加情報の組合せを要求できます。

・ 状態(.STAT, .SEVR):アラーム状態と重要性

・ 単位(.EGU):プロセス変数の単位

・ 精度(.PREC):浮動小数点数を表示するときの精度

・ 時刻(.TS):レコードが最後に処理されたときの時刻

・計数(Enumerated):数値の意味を定義するアスキ文字列

・ グラフィックス(.HOPR, .LOPR):グラフの上限値と下限値

・ 制御(.HOPR, .LOPR):制御範囲の上限値と下限値

・ アラーム:プロセス変数のアラーム値HIHIHIGHLOWおよびLOLO


チャネルアクセスは、データベースレコードをレコードとしてアクセスするのではないことに注意してください。こ れは検討【した/の】結果【/設計上の選択】として決定されました。これ によりチャネルアクセスを介してデータベースにアクセスするソフトウェアに影響を与えずに新しいレコードタイプを使用できるようにし、チャネルアクセスク ライアントがレコードタイプの異なる複数のIOCと通信できるようにするためです。


3.5.2 検索サーバ

チャネルアクセスは、チャネルアクセス検索メッセージを待機するIOC常駐サーバを提供します。チャネルアクセス クライアントがクライアントの使用するプロセス変数を含むIOCを検索するとき(たとえば、オペレータインタフェイスタスク が起動したとき)、発生します。このサーバはすべての検索 メッセージを受信し、プロセス変数がこのIOC内にプロセス変数があるかどうか確認し、該 当するものがあった場合、肯定メッセージを相手に返信します。


3.5.3 接続要求サーバ

プ ロセス変数の場所が確定すると、チャネルアクセスクライアントはクライアントが使用するプロセス変数をもつIOCに接続要求を送信します。IOC内の接続要求サーバは、要求を受信し、クライアント と接続を確立します。接続は2種類のタスクca_getca_putにより管理されます。ca_getca_putは、dbGetFielddbPutFieldデータベース【に/】アクセスを【要求し/マップされ】ます。ca_add_event 要求は、確立されたデータベースモニタに結実しま す。データベースアクセスおよびレコードサポートルーチンは、db_post_eventを呼び出し、モニタ通知を開始します。


3.5.4 接続管理

IOCには、接続管理サービスがあります。チャネ ルアクセスサーバで障害が発生すると(たとえば、IOCのクラッシュ)クライアントに通知され、クライアントで障 害が発生すると(たとえば、タスクのクラッシュ)サーバに通知されます。クライアントに障害 が発生すると、サーバは通信を切断します。サーバに障害が発生したとき、サーバが再起動したときにクライアントは通信を自動的に再開します。


org.page#-27

3.6 OPIツール

EPICSには多数のOPIベースのツールがあります。これらのツール はチャネルアクセスを使うか使わないかにより分類できます。チャネルアクセスツールはリアルタイムツールで、IOCをモニタして制御するのに使用します。


3.6.1 チャネルアクセスツールの例

多数のチャネルアクセスツールが開発されています。以下にその代表例を示します。

EDM-拡張可能ディスプレイマネージャ。EPICS用の最新のディスプレイマネージャ/エディタです。

MEDMMotifバージョンのディスプレイマネージャとディ スプレイエディタの統合ツールです。

DM:ディスプレイマネージャ。EDDが作成した1つ以上のディスプレイリストファイルを読み 込み、すべての必要なIOCとの通信を確立し、プロセス変数をモニタ し、オペレータ制御要求を受信し、すべての変更を反映するようにディスプレイを更新します。

・ストリップツール-汎用ストリップチャートツールです。

ALH:アラームハンドラ。アラーム設定ファイル によりドライブされる汎用アラームハンドラです。

AR:アーカイバ。IOCのデータを取得し保存する汎用ツールです。(Channel Archiverで置き換えられる)

・シーケンサ:IOC内で実行され、有限状態のマシンをエミュ レートします。

BURT:バックアップおよび復旧ツールです。チャ ネルアクセスチャネルを保存し復旧する汎用ツールです。ツールはUnixコマンドまたはグラフィカルユーザインタ フェイスで実行できます。

KM:ノブマネージャ-サンダイアル(8個のノブのセット)のチャネルアクセスインタフェイスです。

PROBE:ユーザは、ランタイムで指定されるシング ルプロセス変数をモニタまたは変更またはその両方を行えます。

CAMATHMathematica用のチャンネルアクセスインタフェイスで す。(メンテナンスされていない?)

CAWINGZWingz用のチャンネルアクセスインタフェイスで す。

IDL/PVWAVE:これら製品にはチャネルアクセスインタ フェイスが存在します。

TCL/TK:この製品のチャネルアクセスインタフェイ スです。

CaPython:Pythong言語のためのインタフェース.FNAL版とKEK版の2種類がある。


3.6.2 その他のOPIツールの例

VDCT-推奨データベース設定ツールになる予定のJavaベースのデータベース設定ツールです。

JDCTJavaデータベース設定ツール。ランタイムデータ ベースを作成するJAVAベースのツールです。

GDCT:グラフィカルデータベース設定ツール。IOCのランタイムデータベースを作成するのに使 います。すでにサポートを停止したunidrawと呼ばれるオープンソースソフトウェアシス テムに基づいて作成されているため、これ以上開発されることはありません。

EDD: ディスプレイエディタ。これはディスプレイマネージャのディスプレイリストファイルを作成するために使用したツールです。ディスプレイリストファイルに は、静的、モニタおよび制御エレメントの一覧があります。モニタと制御エレメントには、対応するプロセス変数があります。

SNC:状態表記【/言語】コンパイラ。IOCシーケンサツールで作成された有限状態マシ ンを表現するC言語プログラムを生成します。

・データベースツール: このツールは、メニューとレコードタイプデータベース定義ファイルからレコード構造体を定義するC言語のincludeファイルを生成します。

・ソース/リリース:EPICSは、EPICSを管理するソース/リリース機構があります。


org.page#-28

3.7 EPICSコアソフトウェア

EPICSはコアソフトウェアとオプション・コンポー ネントで構成されています。コアソフトウェアは、それなしではEPICSが機能しないもので、次のようなものがあり ます。

・ チャネルアクセス – クライアントおよびサーバソフトウェア

IOCデータベース

・スキャナ

・モニタ

・データベース定義ツール

・ソース/リリース


そ の他すべては、オプションのソフトウェアコンポーネントです。もちろん、MEDM(あるいはEDD/DM)を無視するようなアプリケーション開発者はいないで しょう。同様に、アプリケーション開発者はレコードサポートやデバイスサポートをスクラッチから作成することはありません。しかし、大部分のOPIツールは使用【する必要がありません/しなければならないというわけではありません】。同 様に、レコードサポートモジュール、デバイスサポートモジュールまたはドライバを特定のIOCから削除しても、EPICSは適切に機能します。


org.page#-29

4EPICSビルド機能


この章の著者、Janet Anderson


4.1 概要

この章ではEPICSのビルド機能、ファイル構造、環境とシステム要件、設定ファイル、MakeFilesおよび関連するビルドツールについて説明します。


4.1.1 <top>ディレクトリ構造

EPICSソフトウェアは、複数の<top>領域に分類できます。<top>領域の例は、EPICSベースのEPICS拡張子および単純または複合IOCアプリケーションです。<top>は、個別に管理されています。異なる<top>領域がEPICSベースリリースのような外部ソフトウェアの他のリリースに存在します。

<top>ディレクトリには次のディレクトリ構造があります。

<top>/

Makefile

configure/

dir1/

dir2/

...

ここで、configureはビルド設定ファイルが格納されたファイルで、Makefileおよびdir1dir2はユーザが作成するサブディレクトリツリーで、Makefilesとビルドされるソースファイルです。


4.1.2 ディレクトリのインストール

ビルド時にインストールされるファイルは、$(TOP)にデフォルト設定される<top>ディレクトリであるインストールディレクトリにインストールされます。拡張ソフトウェアとアプリケーションで は、デフォルト値はconfigure/CONFIGファイルを上書きできます。EPICSコンポーネントのインストールディレクトリは、次のとおりです。

INSTALL_LOCATION ベース

INSTALL_LOCATION_EXTENSIONS 拡張子

INSTALL_LOCATION_APP アプリケーション


次のディレクトリは、インストールディレク トリに存在します。これらはビルドにより作成され、インストールされたビルドコンポーネントが格納されます。

dbd データベース定義ファイルがインストールされるディレクトリ。

include – C言語のヘッダファイルがインストールされる ディレクトリ。このヘッダファイルは、メニューとレコードタイプの定義により生成されます。

bin このディレクトリには、ホストのアーキテク チャとターゲットのアーキテクチャのサブディレクトリが格納されます。実行可能ファイルおよびバイナリファイルがインストールされます。


org.page#-30

lib このディレクトリにはホストのアーキテク チャのサブディレクトリが格納されます。このディレクトリにライブラリがインストールされます。

db データベース・レコード・インスタンス、テンプレートおよび代替ファイルがインストールされるディレクトリで す。

html – html文書がインストールされるディレクトリです。

templates テンプレートファイルがインストールされるディレクトリです。

javalib – javaクラスファイルとjarファイルがインストールされるディレクトリです。

configure 設定ファイルがインストールされるディレクトリです(INSTALL_LOCATIONTOPにインストールされていない場合)


4.1.3 ビルドシステムのエレメント

ビルドシステムの主要な構成は次のとおりで す。

EPICSベース/設定ディレクトリに付属の設定ファイルやツールのセット

・ビルドされる非ベースの<top>ディレクトリ構造の<top>/設定ディレクトリの中の設定ファイルの該当するセット。makeBaseApp.plmakeBaseExl.plスクリプトによりこの設定ファイルが作成されます。これらのファイルの多くには、ベース/設定ディレクトリと同じ名前のファイルが含まれます。

・ビルドされる<top>ディレクトリ構造の各ディレクトリにおけるMakefiles


4.1.4 特徴

ビルドシステムの基本的な特徴は次のとおり です。

<top>ディレクトリ構造の各ディレクトリに1つのMakefileが必要なこと

・ホストOSのベンダのネイティブコンパイラとGNUコンパイラの両方をサポートすること

1つのディレクトリツリーに保存される複数の種類のソフトウェア(ライブラリ、実行可能ファイル、データベース、javaクラスファイルなど)のビルドをサポートすること

EPICSベース、拡張子およびIOCアプリケーションのビルドをサポートすること

・複数のホストとターゲットオペレーティン グシステムのアーキテクチャの組合せをサポートすること

1つの<top>ソースディレクトリツリーのホストとターゲットをビルドできること

<top>領域で、レコード/デバイス/ドライバのようなコンポーネントを共有できること

gnumake<top>領域をビルドするために使用する唯一つのコマンドであること


4.1.5 複数のホストとターゲットシステム

1つのEPICSディレクトリ構造を使って、複数のホストシステムで、複数のクロスターゲットシステムをビルドすることができま す。ビルドにより作成される中間ファイルとバイナリファイルは、個別のO.*サブディレクトリに作成され、個別のホストまたはターゲットインストールディレクトリにインストールされます。EPICS実行可能ファイルとperlスクリプトは、$(INSTALL_LOCATION)/bin/<arch>

ディレクトリに保存されます。ライブラリ は、$(INSTALL_LOCATION)/lib/<arch>に保存されます。$(INSTALL_LOCATION)のデフォルト定義は、$(TOP)で分散ディレクトリ構造ベースにおけるルートディレクトリです。作成されたファイルでアーキテクチャに依存する もの (たとえば、オブジェクトファイル)は、O.<arch>ソースサブディレクトリに保存され、作成されたファイルでアーキテクチャに依存しないものはO.Commonソースサブディレクトリに保存されます。これにより複数のクロスターゲットアーキテクチャに対するオブジェクト は同時に保持されます。

特定のホスト/ターゲットの組合せに対してEPICSベースを作成するために、適切なホスト/ターゲットc/c++クロスコンパイラとターゲットヘッダファイルが必要で、CROSS_COMPILER_TARGET_ARCHESには、ターゲットの使用が格納され、base/configure/osディレクトリには対応する設定ファイルが必要です。


org.page#-31

4.2 ビルド要件

4.2.1 ホスト環境変数

EPICS<top>領域を作成するには1つの環境変数EPICS_HOST_ARCHだけが必要です。この変数は、ネイティブビルドのためにosベンダのc/c++コンパイラを使用するワークステーションのオペレーティングシステム - アーキテクチャの組合せ、またはシステムが 代替コンパイラをサポートする場合ネイティブビルドのための代替コンパイラを使用するオペレーティングシステム - アーキテクチャ - 代替コンパイラの組合せを設定します。base/configure/osCONFIG.*.Commonファイルのファイル名は、現在サポートしているEPICS_HOST_ARCHの値を示します。たとえば、solaris-sparcsolaris-sparc-gnulinux-x86win32-x86およびwin32-x86-borlandのようになります。


4.2.2 システムの前提条件

EPICSコンポーネントをビルドする前に、ホストシステムに次にソフトウェアがインストールされていることが必要です。

・バージョン5以上のPerl

・バージョン3,78.1以上のGNU make

C++コンパイラ(ホストオペレーティングシステムベンダのコンパイラまたはGNUコンパイラ)

vxWorkターゲット用のEPICSコンポーネントをビルドするには、次のソフトウェアも必要です。

Tornado II1つ以上のボードサポートパッケージ。詳細については、vxWorksの文書を参照してください。


4.2.3 パスとLD_LIBRARY_PATHの要件

パスにperl実行可能ファイルを格納し、検索パスにCC++コンパイラが必要です。ベースをビルドするためには、検索パスにエコーが必要です。


4.2.3.1 Unixパス

Unixホストビルドには、検索パスにtouchcppcprmmvおよびmkdirがあり、/bin/chmodがあることが必要です。Unixシステムによっては、パスにarranlibがあり、パスのldcコンパイラが必要な場合もあります。


4.2.3.2 Unix LD_LIBRARY_PATH

アーカイブライブラリの代わりにEPICSベースの共有ライブラリをビルドする場合、UnixシステムではLD_LIBRARY_PATH環境変数に$(INSTALL_LOCATION)/lib/$(EPICS_HOST_ARCH)へのフルパス名を追加する必要があります。


4.2.3.3 Win32 PATH

WIN32システムでは、共有ライブラリのビルドはデフォルト設定で、パスに$(INSTALL_LOCATION)/bin/$(EPICS_HOST_ARCH)へのフルパス名を追加する必要があります。共有ライブラリをビルドは、マクロSHARED_LIBRARIES in CONFIG_SITEの値により決定されます(YESまたはNO)


4.2.4 起動ファイル

EPICSベースの起動ディレクトリにはperlスクリプトEpicsHostArch.plがあり、EPICS_HOST_ARCHを定義するのに使われます。このスクリプトは、代替コンパイラを定義するコマンドラインパラメータを使って呼び 出すことができます(たとえば、"EpicsHostArch.pl"を呼び出すとsolaris-sparc、次に"EpicsHostArch.pl gnu"を呼び出すとsolaris-sparc-gnuが得られます)


org.page#-32

起動ディレクトリには、ユーザがパスと環境 変数を設定しやすくするスクリプトが格納されています。

4.3 設定定義

4.3.1 サイト指定EPICSベース設定

4.3.1.1 サイト設定

サイトにEPICSベースを設定するには、次のファイルでデフォルト定義を修正します。

configure/CONFIG_SITE ビルドチョイス。ターゲットアーキテクチャの指定

configure/CONFIG_SITE_ENV 環境変数のデフォルト値

configure/RELEASE TORNADO 2フルパスロケーション


4.3.1.2 ホスト設定

サイトにホストシステムを設定するには、上 書き定義を含む新しいファイルを追加することにより、configure/osディレクトリでデフォルト定義を上書きできます。新しいファイルは、名前の中のCONFIGCONFIG_SITEに変更して、配布ファイルと同じ名前にします。

configure/os/CONFIG_SITE.<host>.<host> - ホストのビルド設定

configure/os/CONFIG_SITE.<host>.Common - すべてのターゲットシステムに対するホストのビルド設定


4.3.1.3 ターゲット設定

ターゲットシステムを設定するには、上書き 定義を含む新しいファイルを追加することにより、configure/osディレクトリでデフォルト定義を上書きできます。新しいファイルは、名前の中のCONFIGCONFIG_SITEに変更して、配布ファイルと同じ名前にします。

configure/os/CONFIG_SITE.Common.<target> - ターゲットクロス設定

configure/os/CONFIG_SITE.<host>.<target> - ホスト-ターゲット設定


4.3.1.4 R3.13互換設定

R3.13拡張子とiocアプリケーションを使ってビルドするようにEPICSベースを設定するために、base/configureファイルとbase/configure/osファイルで行ったサイト定義に適合するbase/config/CONFIG_SITE*のデフォルト定義を変更する必要があります。


4.3.2 ディレクトリ定義

設定ファイルには各種のコンポーネントをイ ンストールする定義項目があります。これはすべてINSTALL_LOCATIONに関連しています。INSTALL_LOCATIONのデフォルト値は$(TOP)

で、$(T_A)は現在ビルドしているターゲットのアーキテクチャです。INSTALL_LOCATIONのデフォルト値は、iocアプリケーションのconfigure/CONFIGファイルの最後で上書きされます。


INSTALL_LOCATION_LIB = $(INSTALL_LOCATION)/lib

INSTALL_LOCATION_BIN = $(INSTALL_LOCATION)/bin

INSTALL_HOST_BIN = $(INSTALL_LOCATION_BIN)/$(EPICS_HOST_ARCH)

INSTALL_HOST_LIB = $(INSTALL_LOCATION_LIB)/$(EPICS_HOST_ARCH)


org.page#-33

INSTALL_INCLUDE = $(INSTALL_LOCATION)/include

INSTALL_DOC = $(INSTALL_LOCATION)/doc

INSTALL_HTML = $(INSTALL_LOCATION)/html

INSTALL_TEMPLATES = $(INSTALL_LOCATION)/templates

INSTALL_DBD = $(INSTALL_LOCATION)/dbd

INSTALL_DB = $(INSTALL_LOCATION)/db

INSTALL_CONFIG = $(INSTALL_LOCATION)/configure

INSTALL_JAVA = $(INSTALL_LOCATION)/javalib


ビルドされたファイルでOSに依存しないもののディレクトリ

COMMON_DIR = ../O.Common


INSTALL_LIB = $(INSTALL_LOCATION_LIB)/$(T_A)

INSTALL_SHRLIB = $(INSTALL_LOCATION_LIB)/$(T_A)

INSTALL_TCLLIB = $(INSTALL_LOCATION_LIB)/$(T_A)

INSTALL_BIN = $(INSTALL_LOCATION_BIN)/$(T_A)


4.3.3 拡張子とアプリケーション固有の設定

base/configureディレクトリには、デフォルトのビルド定義とサイト固有のビルド定義のファイルが格納されます。extensions/configureディレクトリには、拡張子に限ったビルド定義(たとえばX11Motifライブラリの場所)base/configureファイルの” "include <filename>"ラインが格納されます。<application>/configureディレクトリにアプリケーション固有のビルド定義が格納され、base/configureファイルが含まれます。CROSS_COMPILER_TARGET_ARCHSのようなビルド定義は、ファイルの定義を上書き置換することにより、拡張子またはアプリケーションを上書きでき ます


4.3.4 RELEASEファイル

<top>/configureディレクトリにはRELEASEファイルが格納されます。RELEASEには、現在の<top>に必要なファイルを含む<top>ディレクトリ構造のユーザ指定一覧を含みます。設定時にmakeが実行されると、perlスクリプトconvertRelease.plは、RELEASEファイルの外部の<top>定義に対するincludebinおよびlibraryディレクトリ定義を含むCONFIG_APP_INCLUDEを生成します。CONFIG_APP_INCLUDEは、CONFIGファイルに含まれ、その定義事項はMakefilesが使用できます。さらに、設定時にmakeが実行されると、perlスクリプトconvertRelease.plは、RELEASEファイルの外部の<top>定義に対する既存のRULES_BUILDファイルに対するinclude宣言を含むRULES_INCLUDEを生成します。RULES_INCLUDEは、EPICSベースのファイルによりインクルードされ、外部<top> RULES_BUILDファイルのすべてのmake規則はMakefilesが使用できます。


たとえば、configure/RELEASEに次の定義が含まれる場合、

CAMAC = /home/epics/modules/bus/camac

作成されたCONFIG_APP_INCLUDEには次のラインが含まれます。

CAMAC_BIN = /home/epics/modules/bus/camac/bin/solaris-sparc

CAMAC_LIB = /home/epics/modules/bus/camac/lib/solaris-sparc

RELEASE_INCLUDES += -I/home/epics/modules/bus/camac/include

RELEASE_DBDFLAGS += -I /home/epics/modules/bus/camac/dbd


作成されたRULES_INCLUDEには次のラインが含まれます。

-include /home/epics/modules/bus/camac/configure/RULES_BUILD


org.page#-34

RELEASE_DBDFLAGSは、dbToRecordTypeHmkmf.plおよびdbExpandツールのコマンドラインに表示され、RELEASE_INCLUDESはコンパイラコマンドラインに表示されます。CAMAC_LIBCAMAC_BINは、Makefileで使われ、スクリプト、実行可能ファイル、オブジェクトファイル、ライブラリまたはその他のファイルの場所を定 義します。

configure/RELEASEの定義は、上書き条件が格納されたconfigure/RELEASE.<epics_host_arch>ファイルを与えることにより、固有のEPICS_HOST_ARCHアークテクチャを上書きします。


4.3.5 configure/RELEASE*の変更

configure/RELEASE*ファイルの定義を追加、変更または削除する前に、<top>レベルディレクトリで"gnumake clean uninstall"を行い、変更を行った後にトップレベルで"gnumake"を行います。

<top>/config/RELEASEファイルには、外部<top>から取得したコンポーネントに関する定義が格納されます。ファイルに定義された新しいリリースにリンクするに は、次のようにします。

cd <top>

gnumake clean uninstall

edit configure/RELEASE

該当するラインを変更して新しいリリースを 指定します。

gnumake

<top>/config/RELEASEのすべての定義は、絶対パスを定義するものである必要であり、相対パス名は使えません。サイトが複数のリリース のベースに対応し、その他のコンポーネントがインストールされている場合、このパス定義には、1つのコンポーネントのリリース番号を加える必要があります。gnumakeRELEASEファイルを読み込むと、このパス名をマクロを使って挿入することができ、たとえば次のようになります。

SUPPORT = /usr/local/iocapps/R3.13.1

EPICS_BASE = $(SUPPORT)/base/3 13 1 asd2


4.3.6 osclassの指定

Makefileの定義はホストシステム(makeが実行されるプラットフォーム)CROSS_COMPILER_TARGET_ARCHSにより定義された各システムに適用されます。

システムに特定の定義だけが適用されるよう に制限することもできます。ほとんどのMakefileの定義は、osclass仕様が続くアンダスコア”_”を付加することで指定します。_<osclass>が指定されていない場合、定義はホストとすべてのCROSS_COMPILER_TARGET_ARCHSシステムに対して適用されます。_<osclass>が指定されている場合、定義は指定したosクラスのシステムだけに適用されます。Makefileの定義には、_DEFAULT仕様も付加できます。_DEFAULTを付加した場合、Makefileの定義は定義の中に_<osclass>がないすべてのシステムに適用されます。定義に_DEFAULTを付加し、この定義を特定のシステム<osclsss>に適用しない場合、値”-nil-“を該当するMakefileの定義に適用する必要があります。

システムには、configure/os/CONFIG.Common.<arch>ファイルにOS_CLASS定義が必要です。数少ない例として以下のようなものがあります。

vxWorks-68040vxWorks-pentiumでは、<osclass>vxWorksです。

solaris-sparcsolaris-x86solaris-sparc-gnuでは、<osclass>solarisです。

win32-x86では、<osclass>WIN32です。

たとえば、次のMakefileラインでは、プロダクトaaaがすべてのシステムに作成される必要があります。プロダクトbbbOS_CLASSsolarisに定義されていないシステムに対して作成されます。

PROD = aaa

PROD_solaris = -nil-

PROD_DEFAULT = bbb


org.page#-35

4.3.7 ホストターゲットとIocターゲット

ビルドによりホストとIOC2種類のmakefileターゲットが作成されます。ホストターゲットは、iocCoreの一部に含まれない実行可能ファイル、オブジェクトファイル、ライブラリおよびスクリプトにです。Iocターゲットは、iocで実行されるiocライブラリ、実行可能ファイル、オブジェクトファイルまたはiocshスクリプトのコンポーネントです。

サポートするターゲットシステムには、サ ポート可能なmakefileターゲットの種類を指定するVALID_BUILD定義があります。この定義は、configure/so/CONFIG.Common.<arch>ファイルまたはconfigure/os/CONFIG.<arch>.<arch>ファイルに現れます。

vxWorksシステムでは、VALID_BUILDS"Ioc"に設定されます。

Unixタイプシステムでは、VALID_BUILDS"Host Ioc"に設定されます。

RTEMSシステムでは、VALID_BUILDS"Ioc"に設定されます。

WIN32システムでは、VALID_BUILDS"Host Ioc"に設定されます。


Makefileでは、特定のPRODTESTPRODLIBRARYSCRIPTおよびOBJSをビルドするシステムに制限できます。たとえば、次のMakefileのラインは、ホストタイプのビルドをサポートするシステムに対してプロダクトaaaが作成されるように指定します。プロダクトbbbIocタイプのビルドをサポートするシステムに対して作成されます。プロダクトcccはすべてのターゲットシステムに対して作成されます。

PROD_HOST = aaa

PROD_IOC = bbb

PROD = ccc

アンダスコア”_”とこれに続けてosclassDEFAULT指定を行うことにより、定義をさらに限定的にすることができます。


4.4 Makefiles

4.4.1 名前

各ディレクトリにおけるmakefileの名前は、Makefileであることが必要です。


4.4.2 インクルードファイル

Makefilesでは、<top>/configureのファイルをインクルードします。makefileの”継承”ルールとconfigureの定義となります。<top>/configureのファイルは、他の<top>/configureのファイルをインクルードします。この方法により、<top>ディレクトリ間で、変数とルールを共有できます。


4.4.3 Makefilesのコンテンツ

サブディレクトリのあるディレクトリでのMakefiles

このようなディレクトリでのMakefileは、<top>がこのディレクトリに対応するもので、<top>/configureファイルをインクルードし、makeを実行するのに好ましい順序でサブディレクトリを指定します。Makefileのラインが後に続くディレクトリ内でgnumakeを実行することにより、gnumakeは先に<dir1>で、次に<dir2>で実行します。ビルドルールでは、Makefileがサブディレクトリとビルドされるコンポーネントの両方を指定することはできません。

TOP=../..

include $(TOP)/configure/CONFIG


org.page#-36

DIRS += <dir1> <dir2>

include $(TOP)/configure/RULES_DIRS


コンポーネントがビルドされるディレクトリ でのMakefiles

このようなディレクトリでのMakefileは、<top>がこのディレクトリに対応するもので、<top> configureファイルをインクルードし、ターゲットコンポーネント定義を指定します。オプションで、ユーザが定義したルール を加えることもできます。このようなMakefileをもつディレクトリでのgnumakeを実行することにより、gnumakeO.<arch>サブディレクトリを作成し、gnumakeを実行してこのサブディレクトリ内で定義済みのコンポーネントをビルドします。次のラインが含まれます。

TOP=../../..

include $(TOP)/configure/CONFIG

<component definition lines>

include $(TOP)/configure/RULES

<optional rules definitions>


4.4.4 簡単なMakefileの例

ソースファイルasDbLib.cからasIocという名前のIOCタイプライブラリを作成し、$(INSTALL_LOCATION)/lib/<arch>ディレクトリにインストールするには、次のようにします。

TOP=../../..

include $(TOP)/configure/CONFIG

LIBRARY_IOC += asIoc

asIoc_SRCS += asDbLib.c

include $(TOP)/configure/RULES


ホストタイプターゲットアーキテクチャで、 既存のEPICSベースのcaライブラリとComライブラリとリンクさせて、ソースファイルcatest1.ccatest2.cからcatestという名前の実行可能ファイルを作成し、catest実行可能ファイルを$(INSTALL_LOCATION)/bin/<arch>ディレクトリにインストールするには、次のようにします。

TOP=../../..

include $(TOP)/configure/CONFIG

PROD_HOST = catest

catest_SRCS += catest1.c catest2


4.5 Make

4.5.1 Makegnumake

EPICSにはmakeルールがあります。このルールは、Free Software Foundationから提供されているmakeGNUバージョンであるgnumakeのみに有効です。したがって、ほとんどのUnixシステムではネイティブのmakeは実行できません。Linuxのようなシステムでは、GNUがデフォルトになっています。このマニュアルでは、例としてgnumakeを取り上げます。


org.page#-37

4.5.2 よく使うMakeコマンド

注:このコマンドのターゲットに<arch>を追加することにより、次のコマンドを単一ターゲットアーキテクチャに適用することができます。

よく使われるコマンドには、次のものがあり ます。

gnumake

更新されていないものをすべて再ビルドして インストールします。

注:引数なしにgnumakeを実行することはgnumake installと同じです。

gnumake <arch>

更新されていない単一の固有ターゲットアー キテクチャをすべて再ビルドしてインストールします。

注:gnumake install.<arch>と同じです。

gnumake clean

gnumakeが作成したO.<arch>ディレクトリを削除することによりディスク容量を節約しますが、bindbdbdなどのディレクトリからインストールされたファイルを削除することはありません。<arch>を追加すると、単一のアーキテクチャに対してcleanを実行できます。

gnumake realclean

このコマンドは、<top>ディレクトリだけで実行できます。すべてのO.<arch>サブディレクトリを削除します(他のEPICS_HOST_ARCHからgnumakeが作成したものも含みます)

gnumake rebuild

このコマンドは、gnumake clean installと同じです。アプリケーション内で作成したファイルの状態がよく分からない場合、gnumake rebuildを実行します。

gnumake uninstall

このコマンドは、<top>ディレクトリだけで実行できます。includelibbindbdbdなどのディレクトリにgnumakeがインストールしたすべてを削除します。

gnumake realuninstall

このコマンドは、<top>ディレクトリだけで実行できます。includelibbindbdbdなどのインストールディレクトリをすべて削除します。

gnumake distclean

このコマンドは、<top>ディレクトリだけで実行できます。これはrealcleanrealuninstallのコマンドを両方とも実行するのと同じです。


4.5.3 Makeターゲット

gnumakeに対して指定できるターゲットの要約を以下に示します。

<action>

<arch>

<action>.<arch>

<dir>

<dir>.<action>

<dir>.<arch>

<dir>.<action>.<arch>

ここで、


org.page#-38

<arch>は、EPICS_HOST_ARCH, solaris-sparc, vxWorks-68040, win32-x86, etc. - 名前のあるアーキテクチャだけをビルドします。

<action>は、helpcleanrealcleandistcleanincinstallbuildrebuildbuildInstallrealuninstallまたはuninstallです。

注:helpuninstalldistcleanおよびrealuninstall<top>だけで使用できます。

注:realclean*.<arch>サブディレクトリでは使用できません。

<dir>はサブディレクトリの名前です。


注:作成された実行可能ファイルやライブラ リは別々のディレクトリ(たとえば、bin/solaris-sparcbin/solaris-sparc-gnu)にインストールされるため、osベンダネイティブのコンパイラを使ってビルドすることや、これに加えて同じディレクトリ構造でサポートする代替 コンパイラを使ってビルドすることもできます。これは、EPICS_HOST_ARCH、ビルド間の環境変数を変更することまたはgnumakeコマンドラインでEPICS_HOST_ARCHを設定することにより行えます。


4.5.4 ヘッダファイルの依存性

プロダクトファイル、テストプロダクトファ イルおよびライブラリソースファイルのすべては、ソースファイル定義(たとえば、SRCSPROD_SRCSLIB_SRCS<prodname>_SRCS)1つにあり、自動的に生成されるヘッダファイル依存性をもち、HDEPENDSMakefileまたはbase/configure/CONFIG_SITEYESに設定されている場合、Makefileの一部としてインクルードされます。


4.6 Makefileの定義

次のコンポーネントは、gnumakeが呼び出されたときに、ビルドされるMakefileにより定義されます。


4.6.1 ソースファイルディレクトリ

通常は、すべてのプロダクト、テストプロダ クトおよびライブラリの各ソースファイルは、Makefileと同じディレクトリに格納されます。OS固有のソースファイルは、サブディレクトリos/<os_class>またはos/posixまたはos/defaultに格納することができます。

ビルドルールでは、ソースファイルをMakefileディレクトリ(srcディレクトリ)のサブディレクトに格納することも許されています。サブディレクトリ<dir>には、ソースファイルにSRC_DIR定義を加えて格納します。

SRC_DIRS += <dir>

ここで、<dir>は相対パス定義で、SRC_DIRSを例とすると、次のようになります。

SRC_DIRS += ../<dir1> ../<dir2>

上記の定義における、ディレクトリ検索順は 次のとおりです。

.

../os/$(OS_CLASS) ../os/posix ../os/default

../dir1/os/$(OS_CLASS) ../dir1/os/posix ../dir1/os/default

../dir2/os/$(OS_CLASS) ../dir2/os/posix ../dir2/os/default

..

../dir1 ../dir2

ここで、ビルドディレクトリO.<os_class>.で、srcディレクトリは..です。


4.6.2 Posix Cのソースコード

epicsベースの設定ファイルでは、posixソースコードを想定し、デフォルトでPOSIXYESに設定しています。個々のMakefilePOSIXNOに設定することで上書きできます。


org.page#-39

4.6.3 ブレークポイントテーブル

ブレークポイントテーブルでは、dbdファイルbpt<table name>.dbdが既存のbpt<table name>.dataファイルから作成され、定義

DBD += bpt<table name>.dbd

Makefileに加えます。次のMakefileでは、既存のbptTypeJdeg.CデータファイルからbptTypeJdegC.dbdが作成され、新しいdbdファイルは$(INSTALL_LOCATION)/dbdディレクトリにインストールされます。

TOP=../../..

include $(TOP)/configure/CONFIG

DBD += bptTypeJdegC.dbd

include $(TOP)/configure/RULES


4.6.4 レコードタイプ定義

新しいレコードタイプには、次の定義がmakefileに追加されます。

DBDINC += <rectype>Record

<rectype>Record.hヘッダファイルは、既存の<rectype>Record.dbdファイルから作成されます。このヘッダは$(INSTALL_LOCATION)/includeディレクトリにインストールされ、dbdファイルは$(INSTALL_LOCATION)/dbdディレクトリにインストールされます。

次のMakefileは既存のxxxRecord.dbdファイルからxxxRecord.hを作成し、xxxRecord.h$(INSTALL_LOCATION)/includeにインストールし、xxxRecord.dbd$(INSTALL_LOCATION)/dbdにインストールします。

TOP=../../..

include $(TOP)/configure/CONFIG

DBDINC += xxxRecord

include $(TOP)/configure/RULES


4.6.5 メニュー

メニューmenu<name>.dbdファイルが存在する場合、次の定義を追加します。

DBDINC += menu<name>.h

menu<name>.hヘッダファイルは、既存のmenu<name>.dbdファイルから作成されます。このヘッダは$(INSTALL_LOCATION)/includeディレクトリにインストールされ、dbdファイルは$(INSTALL_LOCATION)/dbdディレクトリにインストールされます。

次のMakefileは既存のmenuConvert.dbdファイルからmenuConvert.hを作成し、menuConvert.h$(INSTALL_LOCATION)/includeにインストールし、menuConvert.dbd$(INSTALL_LOCATION)/dbdにインストールします。

TOP=../../..

include $(TOP)/configure/CONFIG

DBDINC = menuConvert.h

include $(TOP)/configure/RULES


4.6.6 拡張データベース定義ファイル

他のデータベース定義関数をインクルード済 みの<name>Include.dbdというデータベース定義ファイルは、ユーティリティdbExpandにより作成された<name>.dbdファイルに拡張され、<name>.dbdファイルは$(INSTALL_LOCATION)/dbdにインストールされます。次の変数がプロセスを制御します。

DBD += <name>.dbd


org.page#-40

USR_DBDFLAGS += -I <include path>

USR_DBDFLAGS += -S <macro substitutions>

ここで、エントリは次のようになります。

DBD += <name>.dbd

拡張された定義を含む出力されたdbdファイルの名前。これは既存の<name>Include.dbdファイルから作成され、$(INSTALL_LOCATION)/dbdにインストールされます。拡張するファイルの例は、次のラインを含むexampleInclude.dbdです。

include "base.dbd"

include "xxxRecord.dbd"

device(xxx,CONSTANT,devXxxSoft,"SoftChannel")

USR_DBDFLAGSdbExpandのオプションフラッグを定義します。現在では、インクルードパス(-I<path>)とマクロ関数(-S<substitution>)をサポートしています。EPICSのインクルードパスとその他の<top>/dbdディレクトリは、configure/RELEASEファイルに<top>の名前が指定されていると、ビルド中に自動的に追加されます。

次のMakefileは、既存のexampleInclude.dbdファイルからexample.dbdという拡張dbdファイルを作成し、example.dbd$(INSTALL_LOCATION)/dbdディレクトリにインストールします。

TOP=../../..

include $(TOP)/configure/CONFIG

DBD += exampleApp.dbd

include $(TOP)/configure/RULES


4.6.7 拡張されたデータベース定義ファイルに対す るサポートルーチンの登録

record/device/driverサポートルーチンを登録するソースファイルを作成します。登録のためのルーチン一覧は、既存のdbdファイルにあります。

Makefileの次のラインにより、<name>_registerRecordDeviceDriver.cppを作成し、コンパイルして、<prodname>にリンクします。ファイル<name>.dbdが必要です。

<prodname>_SRCS += <name>_registerRecordDeviceDriver.cpp


4.6.8 データベース定義ファイル

ほとんどのデータベースでは、データベース の名前を指定します。Makeはファイルの作成方法を発見します。

DB += xxx.db

存在するソースファイルに依存してxxx.dbを作成し、$(INSTALL_LOCATION)/dbにインストールします。

*<nn>,dbデータベースファイルは、*.template*<nn>.substitutionsファイルから作成されます(こここで、nnはオプションのインデックス番号)。マクロ関数とインクルードツールのmsiを使って、データベースを作成します。msiはパス内に格納されているか、RELEASEファイルまたはMakefilemsiバイナリファイルにフルパス名を入力して、MSIを再定義する必要があります。

DB += xxx.template xxx.substitutions


org.page#-41

これらのファイルを生成し、インストールし ます。スクリプトにより1つ以上のxxx.substitutionsファイルが作成され、スクリプト名はCREATESUBSTITUTIONS変数(たとえばCREATESUBSTITUTIONS=mySubst.pl)に格納されます。このスクリプトは、引数として生成される挿入ファイル名のプリフィックスを使ってgnumakeが実行します。スクリプトが生成した挿入ファイルがある場合(その場合に限って)、膨張したデータベースの名前のプリフィックスはディレクト内で使われているテンプレートの名前のプリフィック スと同じにならないことがあります。

依存性に関する情報を正しく記録するため に、必要でもインストールされていないすべてのテンプレートファイル(たとえば、DBに一覧されていないもの)は、USES_TEMPLATE変数に追加する必要があります。

USES_TEMPLATE += yyy.template

USES_TEMPLATE += $(SHARE)/installDb/zzz.template

パス(フルパスまたは相対パス)で指定されている場合、テンプレートはO.<arch>ディレクトリにソフトリンク(UNIX)またはコピー(WIN)されます。初めてmakeを実行した後、テンプレート依存性は自動的に作成されます。


4.6.10 コンパイルとリンクコマンドオプション

次のオプションを指定できます。

4.6.10.1 すべてのコンパイル/リンクコマンドのオプション

USR_INCLUDES += -I<name>

"-I"がプリフィックスとなるヘッダファイルディレクトリ。

USR_INCLUDES_<osclass> += <name>

"-I"がプリフィックスとなるos固有のヘッダファイルディレクトリ。

USR_INCLUDES_DEFAULT += <name>

USR_INCLUDE_<osclass>定義のないアーキテクチャに対する"-I"がプリフィックスとなるヘッダファイルディレクトリ。

USR_CFLAGS += <name>

cコンパイラのオプション。

USR_CFLAGS_<osclass> += <name>

os固有のcコンパイラのオプション。

USR_CFLAGS_DEFAULT += <name>

USR_INCLUDE_<osclass>定義のないアーキテクチャに対するcコンパイラのオプション。

USR_CXXFLAGS += <name>

c++コンパイラのオプション。

USR_CXXFLAGS_<osclass> += <name>

指定したosclassに対するc++コンパイラのオプション。

USR_CXXFLAGS_DEFAULT += <name>

USR_INCLUDE_<osclass>定義のないアーキテクチャに対するc++コンパイラのオプション。

USR_CPPFLAGS += <name>

cプリプロセッサのオプション。

USR_CPPFLAGS_<osclass> += <name>

os固有のcプリプロセッサのオプション。

USR_CPPFLAGS_DEFAULT += <name>

USR_INCLUDE_<osclass>定義のないアーキテクチャに対するcプリプロセッサのオプション。

USR_LDFLAGS += <name>

リンカのオプション。

USR_LDFLAGS_<osclass> += <name>

os固有のリンカのオプション。

USR_LDFLAGS_DEFAULT += <name>

USR_INCLUDE_<osclass>定義のないアーキテクチャに対するリンカのオプション。


org.page#-42

4.6.10.2 ターゲット固有のコンパイル/リンクコマンドのオプション

<name>_INCLUDES += -I<name>

"-I"がプリフィックスとなるヘッダファイルディレクトリ。

<name>_INCLUDES_<osclass> += <name>

"-I"がプリフィックスとなるos固有のヘッダファイルディレクトリ。

<name>_CFLAGS += <name>

cコンパイラのオプション。

<name>_CFLAGS_<osclass> += <name>

os固有のcコンパイラのオプション。

<name>_CXXFLAGS += <name>

c++コンパイラのオプション。

<name>_CXXFLAGS_<osclass> += <name>

指定したosclassに対するc++コンパイラのオプション。

<name>_CPPFLAGS += <name>

cプリプロセッサのオプション。

<name>_CPPFLAGS_<osclass> += <name>

os固有のcプリプロセッサのオプション。

<name>_LDFLAGS += <name>

リンカのオプション。

<name>_LDFLAGS_<osclass> += <name>

os固有のリンカのオプション。


4.6.11 ライブラリ

名前、オブジェクト名またはライブラリの コードを格納したソースファイルを指定することにより、ライブラリは作成され、$(INSTALL_LOCATION)/lib/<arch>に保存されます。オブジェクトまたはソースファイルの名前は、ディレクトリのプリフィックスのある状態とない状 態で表示できます。ファイル名に$(EPICS_BASE_BIN)のようなディレクトリのプリフィックスがある場合、特定の場所から取得されます。ディレクトリのプリフィックス が存在しない場合、makeは最初にソースディレクトリの中で特定の名前のファイルを検索し、次に既存の設定ルールを使ってファイルを作成 しようとします。UnixタイプのシステムとvxWorksでは、ライブラリのプリフィックスはlibで、WIN32にはプリフィックスはありません。さらに、ライブラリの種類とターゲットアーキテクチャ(たとえば、.a.so.lib.dll)に適切なライブラリのサフィックスは、ファイルが作成されたときにファイル名に付加されます。


vxWorksの注:R3.14alpha3以降のリリースでは、アーカイブライブラリが作成されます。


共有ライブラリの注:共有ライブラリは任意 またはすべてのホストタイプアーキテクチャに対してビルドされます。base/configure/CONFIG_SITESHARED_LIBRARIES (YES/NO)の定義は、共有またはアーカイブライブラリがビルドされます。SHARED_LIBRARIESYESのとき、アーカイブライブラリと共有ライブラリがビルドされます。この定義は、configure/os/CONFIG_SITE.<arch>.Commonファイルの固有のアーキテクチャに上書きできます。EPICSベースの分散ファイルのSHARED_LIBRARIESのデフォルト定義は、win32ではYESで、その他のホストではNOです。

win32の注:SHARED_LIBRARIES=NOのとき、オブジェクトライブラリファイルが作成され、$(INSTALL_LOCATION)/lib/<arch><name>Obj.libがインストールされます。SHARED_LIBRARIES=YESのとき、3つのライブラリファイルが作成され、$(INSTALL_LOCATION)/lib/<arch><name>.lib<name>Obj.libがインストールされ、$(INSTALL_LOCATION)/bin/<arch>には<name>.dllがインストールされます。(注意:ライブラリからエクスポートされたシンボルが存在する場合、ファイル<name>.libはビルドにより作成されます。) SHARED_LIBRARIES=YESの場合、ディレクトリ$(INSTALL_LOCATION)/bin/<arch>はビルド中にユーザのパスにあり、共有ライブラリとリンクした実行可能ファイルを呼び出します。

Unixホストの注:SHARED_LIBRARIES=YESの場合、共有ライブラリとリンクした実行可能ファイルを呼び出すとき、ディレクトリ$(INSTALL_LOCATION)/lib/<arch>はユーザのLD_LIBRARY_PATHにあります。


4.6.11.1 ライブラリ名の指定

次のいずれかを指定できます。


org.page#-43

LIBRARY += <name>

すべてのターゲットアーキテクチャにライブ ラリが作成されます。

LIBRARY_<osclass> += <name>

ライブラリ<name>は、指定したosclassのすべてのアーキテクチャに対して作成されます。

LIBRARY_DEFAULT += <name>

ライブラリ<name>は、LIBRARY_<osclass>定義のないアーキテクチャに対して作成できます。

LIBRARY_IOC += <name>

ライブラリ<name>は、IOCタイプアーキテクチャに対して作成されます。

LIBRARY_IOC_<osclass> += <name>

ライブラリ<name>は、指定したosclassのすべてのIOCタイプアーキテクチャに対して作成されます。

LIBRARY_IOC_DEFAULT += <name>

ライブラリ<name>は、LIBRARY_IOC_<osclass>定義のないIOCタイプアーキテクチャに対して作成されます。

LIBRARY_HOST += <name>

ライブラリ<name>は、ホストタイプアーキテクチャに対して作成されます。

LIBRARY_HOST_<osclass> += <name>

ライブラリ<name>は、指定したosclassのすべてのホストタイプアーキテクチャに対して作成されます。

LIBRARY_HOST_DEFAULT += <name>

definitionライブラリ<name>は、LIBRARY_IOC_<osclass>定義のないIOCタイプアーキテクチャに対して作成されます。


4.6.11.2 ライブラリソースファイル名の指定

サフィックスのあるソースファイル名は、次のように定義されます。

SRCS += <name>

ソースファイルはすべての定義済みのライブ ラリとプロダクトに対して使用されます。

SRCS_<osclass> += <name>

ソースファイルは、指定したosclassのすべてのアーキテクチャに対するライブラ リとプロダクトを定義するのに使います。

SRCS_DEFAULT += <name>

ソー スファイルは、SRCS_<osclass>定義のないアーキテクチャに対するライブラリとプロ ダクトに使います。

LIBSRCSLIB_SRCSの意味は同じです。LIBSRCSR3.13互換性に適用されます。

LIBSRCS += <name>

ソースファイルは、すべての定義済みのライ ブラリに使われます。

LIBSRCS_<osclass> += <name>

ソースファイルは、指定したosclassのすべてのアーキテクチャの定義済みのライ ブラリに使われます。

LIBSRCS_DEFAULT += <name>

ソー スファイルは、LIBSRCS_<osclass>定義のないアーキテクチャのすべての定義済みのライ ブラリに使われます。


LIB_SRCS += <name>

ソースライフは、すべてのライブラリに対し て使われます。

LIB_SRCS_<osclass> += <name>

ソースファイルは指定したosclassのすべてのアーキテクチャのすべての定義済 みライブラリに使われます。

LIB_SRCS_DEFAULT += <name>

ソースファイルは、LIB_SRCS_<osclass>のないアーキテクチャのすべての定義済みラ イブラリに使われます。


<libname>_SRCS += <name>

ソースファイルは、名前を付けたライブラリ に使われます。

<libname>_SRCS_<osclass> += <name>

ソースファイルは、指定したosclassのすべてのアーキテクチャの名前を付けたラ イブラリに使われます。


org.page#-44

<libname>_SRCS_DEFAULT += <name>

ソー スファイルは、<libname>_SRCS_<osclass>定義のないアーキテクチャの名前の付いたライブラリ に使われます。


4.6.11.3ライブラリオブジェクトファイル名の指定

ライブラリオブジェク トファイル名は、現在のディレクトでビルドされていないオブジェクトファイルに対して指定されます。現在のディレクトリでビルドされたオブジェクトファイ ルは、ライブラリソースファイル名を指定する必要があります。上記のライブラリソースファイル名の指定を参照してください。

".o"または".obj"サフィックスをもつオブジェクトは、次のように定義 され、サフックスなしで指定できますが、次のディレクトリプリフィックスが必要です。

LIB_OBJS += <name>

オブジェクトファイルは、すべてのライブラ リのビルドに使われます。

LIB_OBJS_<osclass> += <name>

オブジェクトファイルは、指定したosclassのアーキテクチャのすべてのライブラリのビ ルドに使われます。

LIB_OBJS_DEFAULT += <name>

オ ブジェクトファイルは、LIB_OBJS_<osclass>のないアーキテクチャのすべてのライブラリのビルド に使われます。

<libname>_OBJS += <name>

オブジェクトファイルは、名前の付いたライ ブラリのすべてのビルドに使われます。

<libname>_OBJS_<osclass> += <name>

オブジェクトファイルは、指定したosclassのアークテクチャのライブラリを作成するの に使われます。

<libname>_OBJS_DEFAULT += <name>

オ ブジェクトファイルは、<libname>_OBJS_<osclass>のないアークテクチャのライブラリを作成するのに使 われます。


R3.13ビルドモジュールと名前に”.o”または”.obj”サフィックスのないアプリケーション(たとえば、xyzLib)から構成されるオブジェクトファイルは次のように定 義されます。

LDOBJS += <name>

オブジェクトファイルは、すべてのライブラリとプロダクトをビルドするのに使われます。

LDOBJS_<osclass> += <name>

オブジェクトファイルは、指定したosclassのアーキテクチャのすべてのライブラリとプ ロダクトのビルドに使われます。

LDOBJS_DEFAULT += <name>

オ ブジェクトファイルは、LIB_OBJS_<osclass>定義のないライブラリとプロダクトのビルドに使われ ます。

<libname>_LDOBJS += <name>

オブジェクトファイルは、名前の付いたライ ブラリのビルドに使われます。

<libname>_LDOBJS_<osclass> += <name>

オブジェクトファイルは、指定したosclassをもつアーキテクチャのライブラリのビルド に使われます。

<libname>_LDOBJS_DEFAULT += <name>

オ ブジェクトファイルは、<libname>_OBJS_<osclass>定義のないアーキテクチャのライブラリのビルドに使 われます。


4.6.11.4 LIBOBJS定義

前のバージョンのepics(3.13以前)では、次のような定義を使えます。

LIBOBJS += $(<support>_BIN)/xxx.o

こ れは、baseLIBOBJSのようなファイルに集められています。このような定 義を使うには、次のラインをインクルードします。

-include ../baseLIBOBJS


org.page#-45

<libname>_OBJS += $(LIBOBJS)

: リリースR3.1.4.0アルファ3以降のベースのmakeBaseApp.plにより作成されるvxWorksアプリケーションには、LIBOBJSという名前のファイルはなく、ベースレコードとデバ イスサポートはアーカイブライブラリにあります。


4.6.11.5 依存ライブラリ名の指定

参 照を解決するために、共有ライブラリには他のライブラリの項目も含まれ、次のように他のライブラリ名を指定できます(ディレクトリプリフィックスおよび& rdquo;.a”または”.so”サフィックスは使いません)

<libname>_LIBS += <name>

<libname>をリンクすると、<name>ライブラリの外部参照が解決されます。

アーカイブライブラリに対するすべての外部参照を解決するために共有ライブラリのビルドに使います。<name>ライブラリには、ディレクトリの場所を指定 する<name>_DIR定義が必要です。


4.6.11.6ライブラリDLLファイル名の指定

WIN32にビルドされたライブラリには、解決するすべての外 部参照が必要で、ライブラリに他のDLLライブラリの項目に対する参照がある場合、DLLライブラリの名前は次のように指定します(ディレクトリプリフィックスなし、& rdquo;dll”サフィックスなし)

DLL_LIBS += <name>

DLLは、すべてのライブラリに対して使用しま す。

<libname>_DLL_LIBS += <name>

DLL名前の付いたライブラリに対して使用しま す。

<name>には、ディレクトリの場所を指定する<name>_DIR定義が必要です。


4.6.11.7共有ライブラリバージョン番号の指定

ライブラリのバージョン番号は、次のように供給ライブラリを作成すると指定できます。

SHRLIB_VERSION += <version>

WIN32では、"/version:$(SHRLIB_VERSION)"リンクオプションになります。Unixタイプホストでは、共有ライブラリ名に".$(SHRLIB_VERSION)"が追加され、バージョン番号のないライブラリ名に対 してシンボリックリンクが作成されます。

$(EPICS_REVISION)は、SHRLIB_VERSIONのデフォルト値です。


4.6.11.8 ライブラリの例

LIBRARY_vxWorks += vxWorksOnly

LIBRARY_IOC += iocOnly

LIBRARY_HOST += hostOnly

LIBRARY += all


vxWorksOnly_OBJS += $(LINAC_BIN)/vxOnly1

vxWorksOnly_SRCS += vxOnly2.c

iocOnly_OBJS += $(LINAC_BIN)/iocOnly1

iocOnly_SRCS += iocOnly2.cpp

hostOnly_OBJS += $(LINAC_BIN)/host1

all_OBJS += $(LINAC_BIN)/all1

all_SRCS += all2.cpp

<top>/configureで定義されるアーキテクチャがsolaris-sparcvxWorks-68040であり、LINAC<top>/CONFIGURE/RELEASEで定義される場合、次のライブラリが作成されます。

$(INSTALL_LOCATION)/bin/vxWork-68040/libvxWorksOnly.a : $(LINAC_BIN)/vxOnly1.o vxOnly2.o

$(INSTALL_LOCATION)/bin/vxWork-68040/libiocOnly.a : $(LINAC_BIN/iocOnly1.o iocOnly2.o


org.page#-46

$(INSTALL_LOCATION)/lib/solaris-sparc/libiocOnly.a : $(LINAC_BIN)/iocOnly1.o iocOnly2.o

$(INSTALL_LOCATION)/lib/solaris-sparc/libhostOnly.a : $(LINAC_BIN)/host1.o

$(INSTALL_LOCATION)/bin/vxWork-68040/liball.a : $(LINAC_BIN)/all1.o all2.o

$(INSTALL_LOCATION)/lib/solaris-sparc/liball.a : $(LINAC_BIN)/all1.o all2.o


4.6.12オブジェクトファイルの作成とイ ンストール

定義を使って、オブジェクトを作成し、インストールできます。

OBJS += <name>

OBJS_<osclass> += <name>

OBJS_DEFAULT += <name>

OBJS_IOC += <name>

OBJS_IOC_<osclass> += <name>

OBJS_IOC_DEFAULT += <name>

OBJS_HOST += <name>

OBJS_HOST_<osclass> += <name>

OBJS_HOST_DEFAULT += <name>

既 存のソースファイルから適切なターゲットアーキテクチャに対して指定したファイルを作成し、$(INSTALL_LOCATION)/bin/<target_arch>にインストールします。


次 のMakefileによりすべてのターゲットアーキテクチャに対してabcオブジェクトファイルが作成され、vxWorksを除くすべてのターゲットアーキテクチャに対してはdefオブジェクトファイルが作成され、vxWorksターゲットアーキテクチャにはxyzオブジェクトファイルのみが作成され、$(INSTALL_LOCATION)/bin/<arch>ディレクトリにインストールされます。

TOP=../../..

include $(TOP)/configure/CONFIG

OBJS += abc

OBJS_vxWorks += xyz

OBJS_DEFAULT += def

include $(TOP)/configure/RULES


4.6.13状態記述プログラム

状態記述プログラムファイルは、SRC定義のソースファイルとして定義できます。 たとえば、次のとおりです。

<prodname>_SRCS += <name>.stt

状 態記述コンパイラsncは、<name>.sttからソースコードを含む<name>.cと、sncプログラムを登録するC++ソースコードを含む<name>_sncreg.cpp2種類のファイルを作成し、これらはシェルから呼び出 すことができます。2つのファイルをコンパイルし、オブジェクトファイル は<prodname>プロダクトにリンクされます。

状 態記述ファイルの拡張子は、.stまたは.sttになります。.sttファイルは、sncにより処理される前にCプリプロセッサに転送されます。

状 態記述言語ソースファイル(*.sttおよび*.st ファイル)がある場合、モジュールseqがビルドされ、RELEASEファイルでSNCSEQが定義されます。cのソース(*.stファイル)に変換する前に、状態記述言語ソースファイルにcプリプロセッシング処理が必要な場合、gccをパスに加える必要があります。


4.6.14スクリプトなど

次のいずれかを指定できます。


org.page#-47

SCRIPT += <name>

スクリプトはsrcディレクトリから$(INSTALL_LOCATION)/bin/<arch>ディレクトリにインストールされます。

SCRIPT_<osclass> += <name>

スクリプト<name>は、指定したosclassのすべてのアーキテクチャに対してインス トールされます。

SCRIPT_DEFAULT += <name>

スクリプト<name>は、SCRIPT_<osclass>定義のないアーキテクチャに対してインストールされ ます。

SCRIPT_IOC += <name>

スクリプト<name>は、Iocタイプのアーキテクチャにインストールされ ます。

SCRIPT_IOC_<osclass> += <name>

スクリプト<name>は、指定したosclassのすべてのIOCタイプアーキテクチャに対してインストール されます。

SCRIPT_IOC_DEFAULT += <name>

スクリプト<name>は、SCRIPT_IOC _<osclass>定義のないIOCタイプアーキテクチャに対してインストールされま す。

SCRIPT_HOST += <name>

スクリプト<name>は、ホストタイプのアーキテクチャにインス トールされます。

SCRIPT_HOST_<osclass> += <name>

スクリプト<name>は、指定したosclassのすべてのホストタイプアーキテクチャに対 してインストールされます。

SCRIPT_HOST_DEFAULT += <name>

ス クリプト<name>は、SCRIPT_HOST _<osclass>定義のないホストタイプアーキテクチャに対してイン ストールされます。


フォームの定義

SCRIPTS_DEFAULT += <name1>

SCRIPTS_<osclass> += <name2>

に より、<name2>スクリプトはsrcディレクトリから$(INSTALL_LOCATION)/bin/<arch>ディレクトリに、osクラス<osclass>のすべてのターゲットアーキテクチャに対してインス トールされ、<name1>スクリプトは他のターゲットアーキテクチャの$(INSTALL_LOCATION)/bin/<arch>ディレクトリにインストールされます。


4.6.15 インクルードファイル

フォームの定義

INC += <name>.h

に より、ファイル<name>.hsourceディレクトリから$(INSTALL_LOCATION)/includeディレクトリにインストールされます。

フォームの定義

INC_DEFAULT += <name>.h

INC_<osclass> += <name>.h

に より、ファイル<name>.hsourceディレクトリから$(INSTALL_LOCATION)/include/os/<osclass>ディレクトリにインストールされます。


4.6.16 HtmlファイルとDocファイル

フォームの定義

HTMLS_DIR = <dirname>

HTMLS += <name>

に より、ファイル<name>srcディレクトリから$(INSTALL_LOCATION)/ html/<dirname>ディレクトリにインストールされます。


org.page#-48

DOCS += <name>

に より、ファイル<name>srcディレクトリから$(INSTALL_LOCATION)/docディレクトリにインストールされます。


4.6.17 テンプレート

追加したフォームの定義

TEMPLATES_DIR = <dirname>

TEMPLATES += <name>

に より、ファイル<name>srcディレクトリから$(INSTALL_LOCATION)/ templates/<dirname>ディレクトリにインストールされます。テンプレート ファイルのディレクトリ構造がインストールされた場合、テンプレートファイル名には、ディレクトリのプリフィックスが含まれることがあります。


4.6.18 Lexyac

Makefile定義で指定される<name>.cソースファイルがソースディレクトリに認められない 場合、gnumakeはソースディレクトリで<name>.yファイルと<name>_lex.lファイルをビルドしようとします。


4.6.19 プロダクト

プ ロダクト実行ファイルは、名前とプロダクトに対するコードを含むオブジェクトまたはソースファイルの名前を指定することにより、それぞれの<arch>に対して作成され、にインストールされます。オブ ジェクトファイルまたはソースファイルの名前は、ディレクトリのプリフィックスの有無にかかわらず表示されます。オブジェクトファイルには、ディレクトリ のプリフィックスが含まれます。ファイルに$(EPICS_BASE_BIN)のようなディレクトリプリフィックスがある場合、 ファイルは指定した場所から取り出されます。ディレクトリプリフィックスがない場合、makeは指定した名前のファイルをソースディレクトリ内で 検索し、既存のルールを使ってビルドしようとします。ターゲットアーキテクチャに対する実行可能ファイル名のサフィックス(たとえば.exe)は、ファイルが作成されたときにファイル名に追加さ れます。

vxWorksターゲットアーキテクチャに対するMakefilePROD仕様により、解決したライブラリ参照と対応 する.munchファイルを組み合わせたオブジェクトファイ ルを作成します。

<PROD += <name>

<name>_SRC += <srcname>.c

に より、<srcname>.cファイルからホストタイプ<arch>に対して実行可能な<name>ビルドされます。次に<name>$(INSTALL_LOCATION)/bin/<arch>ディレクトリにインストールされます。


4.6.19.1 プロダクト名の指定

次のいずれも指定できます。

PROD += <name>

プロダクト<name>は、すべてのホストタイプターゲットアーキ テクチャに対して作成されます。

PROD_<osclass> += <name>

プロダクト<name>は、指定したosclassのすべてのアーキテクチャに対して作成され ます。

PROD_DEFAULT += <name>

プ ロダクト<name>は、PROD_<osclass>定義のないホストタイプアーキテクチャに対して作成 されます。

PROD_IOC += <name>

プロダクト<name>は、IOCタイプアーキテクチャに対して作成されま す。

PROD_IOC_<osclass> += <name>

プロダクト<name>は、指定したosclassIOCタイプアーキテクチャに対して作成されま す。

PROD_IOC_DEFAULT += <name>


org.page#-49

プ ロダクト<name>は、PROD_IOC _<osclass>定義のないIOCタイプアーキテクチャに対して作成されます。

PROD_HOST += <name>

プロダクト<name>は、ホストタイプアーキテクチャに対して作 成されます。

PROD_HOST_<osclass> += <name>

プロダクト<name>は、指定したosclassのすべてのホストタイプアーキテクチャに対 して作成されます。

PROD_HOST_DEFAULT += <name>

プ ロダクト<name>は、PROD_ HOST _<osclass>定義のないホストタイプアーキテクチャに対して作成 されます。


4.6.19.2 プロダクトオブジェクトファイル名の指定

ファ イル名にサフィックス”.o”または”.obj”があるオブジェクトファイルは次のように定義され、 サフィックス無しでディレクトリのプリフィックスにより指定できます。

PROD_OBJS += <name>

オブジェクトファイルはすべてのプロダクト のビルドに使われます。

PROD_OBJS_<osclass> += <name>

オブジェクトファイルは、指定したosclassのアーキテクチャに対するすべてのプロダク トをビルドするのに使います。

PROD_OBJS_DEFAULT += <name>

オ ブジェクトファイルは、PROD_OBJS_<osclass>のないアーキテクチャに対するすべてのプロダクトを ビルドするのに使います。

<prodname>_OBJS += <name>

オブジェクトファイルは、名前の付いたプロ ダクトのビルドに使います。

<prodname>_OBJS_<osclass> += <name>

オブジェクトファイルは、指定したosclassのアーキテクチャに対する名前の付いたプロ ダクトをビルドするのに使います。

<prodname>_OBJS_DEFAULT += <name>

オ ブジェクトファイルは、PROD_OBJS_<osclass>定義のないアーキテクチャに対する名前の付いたプロ ダクトをビルドするのに使います。


R3.13ビルドモジュールとサフィックス& rdquo;.o”または”.obj”を含まない(たとえば、xyzLib)アプリケーションを組み合わせたオブジェクトファイ ルは、次のように定義されます。

LDOBJS += <name>

オブジェクトファイルはすべてのライブラリ とプロダクトをビルドするために使われます。

LDOBJS_<osclass> += <name>

オブジェクトファイルは、指定したosclassのアーキテクチャに対するすべてのライブラ リとプロダクトをビルドするのに使われます。

LDOBJS_DEFAULT += <name>

オ ブジェクトファイルは、LDOBJS_<osclass>定義のないアーキテクチャに対するすべてのライブラ リとプロダクトをビルドするのに使われます。

<prodname>_LDOBJS += <name>

オブジェクトファイルは、すべての名前の付 いたプロダクトをビルドするのに使われます。

<prodname>_LDOBJS_<osclass> += <name>

オブジェクトファイルは、指定したosclassのアーキテクチャに対する名前の付いたプロ ダクトをビルドするのに使われます。

<prodname>_LDOBJS_DEFAULT += <name>

オ ブジェクトファイルは、LDOBJS_<osclass>定義のないアーキテクチャに対するプロダクトをビル ドするのに使われます。


4.6.19.3 プロダクトソースファイル名の指定

サフィックスが必要なファイル名は次のように定義します。

SRCS += <name>

ソースファイルはすべての定義されたライブラリとプロダクトに使われます。

SRCS_<osclass> += <name>


org.page#-50

ソースファイルは、指定したosclassのアーキテクチャに対する定義されたライブ ラリとプロダクトに使われます。

SRCS_DEFAULT += <name>

ソー スファイルは、SRCS_<osclass>のないアーキテクチャに対する定義されたライブラリ とプロダクトに使われます。

PROD_SRCS += <name>

ソースファイルはすべてのプロダクトに使われます。

PROD_SRCS_<osclass> += <name>

ソースファイルは、指定したosclassのすべてのアーキテクチャに対する定義され たプロダクトに使われます。

PROD_SRCS_DEFAULT += <name>

ソー スファイルは、PROD_SRCS_<osclass>定義のないアーキテクチャに対する定義されたプロダ クトに使われます。

<prodname>_SRCS += <name>

ソースファイルは名前の付いたプロダクトに 使われます。

<prodname>_SRCS_<osclass> += <name>

ソースファイルは、指定したosclassのすべてのアーキテクチャに対する名前の付 いたプロダクトに使われます。

<prodname>_SRCS_DEFAULT += <name>

ソー スファイルは、<prodname>_SRCS_<osclass>定義のないアーキテクチャに対する名前の付いたプロ ダクトに使われます。


4.6.19.4 プロダクトを作成したときにリンクするライブラリの 指定

システムライブラリでもEPICS_BASEのライブラリでもないライブラリ名を指定す るには、<lname>_DIR定義がMakefile内に必要で、ライブラリの場所を指定しま す。

ディレクトリプリフィックスもサフィックスもないライブラリ名は次のように定義します。

PROD_LIBS += <name>

すべての定義したプロダクトとリンクすると きに使うライブラリ。

PROD_LIBS_<osclass> += <name>

すべての定義したプロダクトとリンクするときに、使うライブラリまたは指定したosclassのすべてのアーキテクチャ。

PROD_LIBS_DEFAULT += <name>

す べての定義したプロダクトとリンクするときに、PROD_LIBS_<osclass>定義のないアーキテクチャに対して使うライブラリ。

USR_LIBS += <name>

すべての定義したプロダクトとリンクするときに使うライブラリ。

USR_LIBS_<osclass> += <name>

すべての定義したプロダクトとリンクするときに、使うライブラリまたは指定したosclassのすべてのアーキテクチャ。

USR_LIBS_DEFAULT += <name>

す べての定義したプロダクトとリンクするときに、USR_LIBS_<osclass>定義のないアーキテクチャに対して使うライブラリ。

<prodname>_LIBS += <name>

名前の付いたプロダクトとリンクするときに 使うライブラリ。

<prodname>_LIBS_<osclass> += <name>

名前の付いたプロダクトとリンクするとき に、使うライブラリまたは指定したosclassのすべてのアーキテクチャ。

<prodname>_LIBS_DEFAULT += <name>

名 前の付いたプロダクトとリンクするときに、<prodname>_LIBS_<osclass>定義のないアーキテクチャに対して使うライブラリ。

SYS_PROD_LIBS += <name>

すべての定義したプロダクトとリンクすると きに使うシステムライブラリ。


org.page#-51

SYS_PROD_LIBS_<osclass> += <name>

すべての定義したプロダクトとリンクするときに、使うシステムライブラリまたは指定したosclassのすべてのアーキテクチャ。

SYS_PROD_LIBS_DEFAULT += <name>

すべての定義したプロダクトとリンクするときに、PROD_LIBS_<osclass>定義のないアーキテクチャに 対して使うシステムライブラリ。

<prodname>_SYS_LIBS += <name>

名前の付いたプロダクトとリンクするときに 使うシステムライブラリ。

<prodname>_SYS_LIBS_<osclass> += <name>

システムライブラリは、名前の付いたプロダ クトとリンクするために、指定したosclassのすべてのアーキテクチャに使われます。

<prodname>_SYS_LIBS_DEFAULT += <name>

名 前の付いたプロダクトとリンクするときに、<prodname>_LIBS_<osclass>定義のないアーキテクチャに対して使うシステムライ ブラリ。


4.6.19.5 プロダクトのバージョン番号の指定

WIN32上だけで、プロダクトのバージョン番号を次 のように指定できます。

PROD_VERSION += <version>

こ れにより、"/version:$(PROD_VERSION)"リンクオプションが変更されます。


4.6.20 テストプロダクト

テ ストプロダクトは、$(INSTALL_LOCATION)/bin/<arch>ディレクトリに作成され、インストールされない実行 可能ファイルです。テストプロダクトライブラリ、ソースおよびオブジェクトファイルは、通常のプロダクトと同じ方法で指定されます。

次の事項を指定できます。

TESTPROD += <name>

テストプロダクト<name>は、どのターゲットアーキテクチャにも作成 されます。

TESTPROD_<osclass> += <name>

テストプロダクト<name>は、指定したosclassのすべてのアーキテクチャに対して作成され ます。

TESTPROD_DEFAULT += <name>

テストプロダクト<name>は、TESTPROD_<osclass>定義のないアーキテクチャに対して作成されます。

TESTPROD_IOC += <name>

テストプロダクト<name>は、IOCタイプアーキテクチャに対して作成されま す。

TESTPROD_IOC_<osclass> += <name>

テストプロダクト<name>は、指定したosclassIOCアーキテクチャに対して作成されます。

TESTPROD_IOC_DEFAULT += <name>

テストプロダクト<name>は、TESTPROD_IOC_<osclass>のないIOCアーキテクチャに対して作成されます。

TESTPROD_HOST += <name>

テストプロダクト<name>は、ホストタイプアーキテクチャに対して作 成されます。

TESTPROD_HOST_<osclass> += <name>

テストプロダクト<name>は、指定したosclassのホストアーキテクチャに対して作成されま す。

TESTPROD_HOST_DEFAULT += <name>

テ ストプロダクト<name>は、TESTPROD_HOST_<osclass>のないホストアーキテクチャに対して作成されます。


4.6.21 ターゲットファイル

フォームの定義


org.page#-52

TARGETS += <name>

により、ソースディレクトリの既存のルールとファイルから、O.<arch>ディレクトリにファイル<name>がビルドされます。このターゲットファイル はインストールされません。


4.6.22 Binインストールファイル

フォームの定義

BIN_INSTALLS += <name>

BIN_INSTALLS_DEFAULT += <name>

BIN_INSTALLS_<osclass> += <name>

に より、ファイルは$(INSTALL_LOCATION)/bin/<arch>ディレクトリにインストールされます。ファイル<name>ディレクトリプリフィックスの有無にかかわらず表示 されます。ファイルに$(EPICS_BASE_BIN)のようなディレクトリプリフィックスがある場合、指 定した場所からコピーされます。ディレクトリプリフィックスがない場合、makesourceディレクトリ内でファイルを検索します。


4.6.23 Win32リソースファイル

フォームの定義

RCS += <name>

RCS_DEFAULT += <name>

<library or product name>_RCS_win32 += <name>

により、指定した*.rcファイルからリソースファイル(*.resファイル)が作成され、すべてのプロダクトとライブラ リにリンクされ、または最後のラインで指定しプロダクトまたはライブラリの実行ファイルだけにリンクします。


4.6.24 TCLライブラリ

フォームの定義

TCLLIBNAME += <name>

TCLINDEX += <name>

に より、指定したtclファイルが$(INSTALL_LOCATION)/lib/<arch>ディレクトリにインストールされます。


4.6.25 Javaクラスファイル

Javaクラスファイルは、javacツールにより、Makefilejavaクラスファイルの名前を指定して、$(INSTALL_JAVA)またはO.Commonサブディレクトリに作成されます。javacツールのコマンドラインオプションを指定できます。 設定ファイルにより、java cオプション"-sourcepath .:..:../.."を設定します。

次のように指定できます。

JAVA += <name>.java

<name>.javaファイルは、$(INSTALL_JAVA)ディレクトに<name>.classファイルを作成するのに使われます。

TESTJAVA += <name>.java

<name>. javaファイルは、O.Commonサブディレクトに<name>.classファイルを作成するのに使われます。

USR_JAVACFLAGS += <name>

javacオプション<name>は、javacコマンドラインで使われます。


org.page#-53

4.6.25.1 1

こ の例では、3種類のクラスファイルが$(INSTALL_LOCATION)/javalib/mytestに作成されます。Javac depreciationフラグを使って、不適切になったメンバまたはクラス の使用または上書き定義を示します。

JAVA = mytest/one.java

JAVA = mytest/two.java

JAVA = mytest/three.java

USR_JAVACFLAGS = -deprecation


4.6.25.2 2

この例では、O.Commonサブディレクトリにtest.classファイルが作成されます。

TESTJAVA = test.java


4.6.26 Java jarファイル

java jarツールを使って、1つのjava jarファイルが作成され、名前および作成されたjarファイルにインクルードされる入力ファイルの名前を 指定することにより、$(INSTALL_JAVA) (たとえば $(INSTALL_LOCATION)/javalib)にインストールできます。jar入力ファイル名は、ディレクトリプリフィックスが使 われる必要があります。

次の項目を指定できます。

JAR += <name>

<name> jarファイルが作成され、$(INSTALL_JAVA)ディレクトリにインストールされます。

JAR_INPUT += <name>

画像ファイル、音声ファイルおよびクラス ファイルの名前はjarファイルに加えられます。

JAR_MANIFEST += <name>

既存のマニフェストファイルは、作成されたjarファイルに使用されます。


4.6.26.1 1

こ の例では、現在のMakefile"CLASSES+="定義によりすべてのクラスファイルが作成され、ファ イル名mytest1.jarに格納されます。

: $(INSTALL_CLASSES)は、EPICSベース設定ファイルの$(addprefix $(INSTALL_JAVA)/,$(CLASSES))にセットされます。

JAR = mytest1.jar

JAR_INPUT = $(INSTALL_CLASSES)


4.6.26.2 2

こ の例では、3つのクラスファイルが作成され、mytest2.jarという新しいjarアーカイブファイルに格納されます。既存のマニフェ ストファイルmytest2.mfは、新しいjarファイルに格納されます。

JAR = mytest2.jar

JAR_INPUT = $(INSTALL_JAVA)/mytest/one.class

JAR_INPUT = $(INSTALL_JAVA)/mytest/two.class

JAR_INPUT = $(INSTALL_JAVA)/mytest/three.class

JAR_MANIFEST = mytest2.mf


org.page#-54

4.6.27 Java native method C header files

javaネイティブな方法に使うCヘッダファイルは、作成するヘッダファイル の名前を指定することにより、O.Commonサブディレクトリのjavahツールが作成します。ヘッダを生成するのに 使うjavaクラスファイルの名前は、ヘッダファイルの 名前から引用されます。アンダスコア(_)をヘッダファイル名のデリミタとして使いま す。javahツールのコマンドラインオプションを指定す ることもできます。

次のように指定できます。

JAVAINC += <name>.h

O.Commonサブディレクトリに<name>.hヘッダファイルが作成されます。

USR_JAVAHFLAGS += <name>

javahオプション<name>javahツールコマンドラインで使います。


4.6.27.1

こ の例では、Cヘッダxx_yy_zzはクラスxx.yy.zzから$(COMMON_DIR)サブディレクトリに作成されます(たとえば、javaクラスファイル$(INSTALL_JAVA)/xx/yy/zz.class)。オプション"-old"javahに従来のJDK1.0のスタイルヘッダファイルを作成するように指示しま す。

JAVAINC = xx_yy_zz.h

USR_JAVAHFLAGS = -old


4.7 Makefile定義の表

以 下に示す<osclass>を含む定義は、特定のosclassのターゲットアーキテクチャに対してビルドするとき に使われ、名前の<osclass>の部分は、solarisvxWorksなどのような必要なosclassで置き換えられます。_DEFAULT設定が与えられていても、特定な<osclass>がデフォルトを適用せず、<osclass>に適用する定義に項目がない場合、値& rdquo;-nil-“は該当するMakefile定義で指定されます。

オプションについて

ビルドされるプロダクト

(ホ ストタイプアーキテクチャのみ)

PROD ビ ルドし、インストールするプロダクト(実 行サフィックスのない名前)xyzと 指定すると、Unixで は実行可能ファイルxyzWIN32で はxyz.exeを ビルドします。

PROD_<osclass> <osclass>アー キテクチャのみにビルドされ、インストールされるosク ラス固有のプロダクト

PROD_DEFAULT PROD_<osclass>を 指定していないアーキテクチャにビルドされ、インストールされるプロダクト

PROD_IOC iocタ イプアーキテクチャにビルドされ、インストールされるプロダクトの名前

PROD_IOC_<osclass> iocタ イプアーキテクチャにビルドされ、インストールされるos固 有のプロダクト

PROD_IOC_DEFAULT PROD_IOC_<osclass>を 指定していないiocタ イプアーキテクチャシステムにビルドされ、インストールされるプロダクト

PROD_HOST ホ ストタイプアーキテクチャにビルドされ、インストールされるプロダクトの名前

PROD_HOST_<osclass> <osclass>タ イプアーキテクチャにビルドされ、インストールされるosク ラス固有のプロダクト

PROD_HOST_DEFAULT PROD_HOST_<osclass>を 指定していないアーキテクチャシステムにビルドされ、インストールされるプロダクト


org.page#-55

ビルドされるテストプロダ クト(ホ ストタイプアーキテクチャのみ)

TESTPROD ビ ルドされてもインストールされないテストプロダクト(実 行サフィックスのない名前)

TESTPROD_<osclass> ビ ルドされてもインストールされないosク ラス固有のテストプロダクト

TESTPROD_DEFAULT ビ ルドされてもインストールされないTESTPROD_<osclass>が 指定されていないアーキテクチャに対するテストプロダクト

TESTPROD_IOC iocタ イプアーキテクチャにビルドされ、インストールされるテストプロダクトの名前

TESTPROD_IOC_<osclass> iocタ イプアーキテクチャにビルドされ、インストールされるテストプロダクトの名前

TESTPROD_IOC_DEFAULT PROD_IOC_<osclass>を 指定していないiocタ イプアーキテクチャシステムにビルドされ、インストールされるテストプロダクト

TESTPROD_HOST ホ ストタイプアーキテクチャにビルドされ、インストールされるテストプロダクトの名前

TESTPROD_HOST_<osclass> <osclass>タ イプアーキテクチャにビルドされ、インストールされるosク ラス固有のテストプロダクト

TESTPROD_HOST_DEFAULT PROD_HOST_<osclass>を 指定していないアーキテクチャシステムにビルドされ、インストールされるテストプロダクト

ビルドされるライブラリ

LIBRARY ビ ルドされ、インストールされるライブラリの名前。名前にはプリフィックスや拡張子を加えず、たとえばCaと 指定すると、Unixで はlibCa.aWIN32で はCa.libCaObj.libま たはCa.dllが ビルドされます。

LIBRARY_<osclass> ビ ルドされ、インストールされるosク ラス固有のライブラリ

LIBRARY_DEFAULT LIBRARY _<osclass>を 指定していないアーキテクチャシステムにビルドされ、インストールされるライブラリ

LIBRARY_IOC iocタ イプアーキテクチャにビルドされ、インストールされるライブラリの名前。名前にはプリフィックスや拡張子を加えず、たとえばCaと 指定すると、Unixで はlibCa.aWIN32で はCa.libCaObj.libま たはCa.dllが ビルドされます。

LIBRARY_IOC_<osclass> iocタ イプアーキテクチャにビルドされ、インストールされるosク ラス固有のライブラリ

LIBRARY_IOC_DEFAULT LIBRARY_IOC _<osclass>を 指定していないiocタ イプアーキテクチャシステムにビルドされ、インストールされるライブラリ

LIBRARY_HOST ホ ストタイプアーキテクチャにビルドされ、インストールされるライブラリの名前。名前にはプリフィックスや拡張子を加えず、たとえばCaと 指定すると、Unixで はlibCa.aWIN32で はCa.libCaObj.libま たはCa.dllが ビルドされます。

LIBRARY_HOST_<osclass> ホ ストタイプアーキテクチャにビルドされ、インストールされるosク ラス固有のライブラリ

LIBRARY_HOST_DEFAULT LIBRARY_HOST _<osclass>を 指定していないホストタイプアーキテクチャシステムにビルドされ、インストールされるライブラリ

SHARED_LIBRARIES 共 有ライブラリをビルドするかどうか。YESま たはNOで 答える必要があります。

SHRLIB_VERSION 共 有ライブラリのバージョン番号

SHRLIB_LIBS 作 成した共有ライブラリにリンクするライブラリ

SHRLIB_LIBS_<osclass> 作 成した共有ライブラリにリンクするosク ラス固有のライブラリ


org.page#-56

SHRLIB_LIBS_DEFAULT SHRLIB_LIBS_<osclass>を 指定していないホストタイプアーキテクチャシステムに作成した共有ライブラリにリンクするライブラリ

プロダクトとライブラリの ソースファイル

SRCS す べてのPRODLIBRARYを ビルドするソースファイル

SRCS_<osclass> す べてのPRODLIBRARYを ビルドするosclass固 有のソースファイル

SRCS_DEFAULT SRCS_<osclass>を 指定していないアーキテクチャに対してすべてのPRODLIBRARYを ビルドするソースファイル

PROD_SRCS す べてのPRODを ビルドするソースファイル

PROD_SRCS_<osclass> す べてのPRODを ビルドするosclass固 有のソースファイル

PROD_SRCS_DEFAULT SRCS_<osclass>を 指定していないアーキテクチャに対してすべてのPRODを ビルドするのに必要なソースファイル

LIB_SRCS LIBRARY を ビルドするソースファイル(た とえば、LIB_SRCS=la.c lb.c lc.c)

LIB_SRCS_<osclass> os固 有のライブラリソースファイル

LIB_SRCS_DEFAULT LIB_SRCS_<osclass>を 指定していないアーキテクチャに対するライブラリソースファイル

<name>_SRCS 固 有のPRODま たはLIBRARYを ビルドするソースファイル

<name>_SRCS_<osclass> 固 有のPRODま たはLIBRARYを ビルドするos固 有のソースファイル

<prod>_SRCS_<osclass>を 指定していないアーキテクチャに対して固有のPRODま たはLIBRARYを ビルドするのに必要なソースファイル

プロダクトとライブラリの オブジェクトファイル

PROD_OBJS サ フィックスを使わずに指定されたすべてのPRODを ビルドするオブジェクトファイル

PROD_OBJS_<osclass> サ フィックスを使わずに指定されたすべてのPRODを ビルドするosclass固 有のオブジェクトファイル

PROD_OBJS_DEFAULT OBJS_<osclass>を 指定していないアーキテクチャに対して、PRODを ビルドするのに必要で、サフィックスを使わずに指定されたオブジェクトファイル

LIB_OBJS サ フィックスを使わずに指定されたすべてのLIBRARYを ビルドするオブジェクトファイル(た とえば、LIB_OBJS+=$(AB_BIN)/la $(AB_BIN)/lb)

LIB_OBJS_<osclass> サ フィックスを使わずに指定されたos固 有のライブラリオブジェクトファイル

LIB_OBJS_DEFAULT LIB_OBJS_<osclass>を 指定していないアーキテクチャに対して、サフィックスを使わずに指定されたライブラリオブジェクトファイル

<name>_OBJS サ フィックスを使わずに指定されたPRODま たはLIBRARYを ビルドするオブジェクトファイル

<name>_OBJS_<osclass> サ フィックスを使わずに指定されたPRODま たはLIBRARYを ビルドするos固 有のオブジェクトファイル

<name>_OBJS_DEFAULT <prod>_OBJS_<osclass>を 指定していないアーキテクチャに対して、PRODま たはLIBRARYを ビルドするのに必要で、サフィックスを使わずに指定されたオブジェクトファイル

LDOBJS す べてのPRODLIBRARYを ビルドするのに必要で、サフィックスのないフィル名をもつオブジェクトファイル(た とえば、LDOBJS+=$(XYZ_BIN)/xyzLib)


org.page#-57

LDOBJS_<osclass> サ フィックスのないファイル名をもつos固 有のオブジェクトファイル

LDOBJS_DEFAULT LDOBJS_<osclass>を 指定していないアーキテクチャに対するサフィックスのないフィル名をもつオブジェクトファイル

<name>_LDOBJS 指 定したPRODま たはLIBRARYを ビルドするのに必要で、サフィックスのないフィル名をもつオブジェクトファイル

<name>_LDOBJS_<osclass> 指 定したPRODま たはLIBRARYを ビルドするのに必要で、サフィックスのないフィル名をもつos固 有のオブジェクトファイル

<name>_LDOBJS_DEFAULT <name>_LDOBJS_<osclass>を 指定していないアーキテクチャに対して、指定したPRODま たはLIBRARYを ビルドするのに必要で、サフィックスのないフィル名をもつオブジェクトファイル

コンパイラのフラグ

USR_CFLAGS シ ステム全体に対するCコ ンパイラのフラッグ

USR_CFLAGS_<osclass> os固 有のCコ ンパイラのフラッグ

USR_CFLAGS_DEFAULT USR_CFLAGS_<osclass>を 指定していないアーキテクチャに対するCコ ンパイラのフラッグ

<name>_CFLAGS ファ イル固有のCコ ンパイラのフラッグ(た とえば、xxxRecord_CFLAGS=-g)

<name>_CFLAGS_<osclass> osク ラスに対するファイル固有のCコ ンパイラのフラッグ

USR_CXXFLAGS シ ステム全体に対するC++コ ンパイラのフラッグ(た とえば、xyxMain_CFLAGS=-DSDDS)

USR_CXXFLAGS_<osclass> os固 有のC++コ ンパイラのフラッグ

USR_CXXFLAGS_DEFAULT USR_CFLAGS_<osclass>を 指定していないアーキテクチャに対するC++コ ンパイラのフラッグ

<name>_CXXFLAGS ファ イル固有のC++コ ンパイラのフラッグ

<name>_CXXFLAGS_<osclass> osク ラスに対するファイル固有のC++コ ンパイラのフラッグ

USR_CPPFLAGS Cプ リプロセッサのフラグ(す べてのmakefileコ ンパイルに対して)

USR_CPPFLAGS_<osclass> os固 有のcppフ ラグ

USR_CPPFLAGS_DEFAULT USR_CPPFLAGS_<osclass>を 指定していないシステムに対するcppフ ラグ

<name>_CPPFLAGS ファ イル固有のCプ リプロセッサのフラッグ(た とえば、xxxRecord_CPPFLAGS=-DDEBUG)

<name>_CPPFLAGS_<osclass> osク ラスに対するファイル固有のcppフ ラグ

USR_INCLUDES -Iプ リフィックスのあるディレクトリでインクルードファイルを検索します(た とえば、 -I$(EPICS_EXTENSIONS_INCLUDE))

USR_INCLUDES_<osclass> -Iプ リフィックスのあるディレクトリで固有のosク ラスに対するインクルードファイルを検索します

USR_INCLUDES_DEFAULT -Iプ リフィックスのある<name>_INCLUDES_<osclass>を 指定していないシステムでインクルードファイルを検索します

<name>_INCLUDES -Iプ リフィックスのあるディレクトリで、指定したオブジェクトファイルをビルドするときインクルードファイルを検索します(た とえば、-I$(MOTIF_INC))

ビルドオプションの説明


org.page#-58

<name>_INCLUDES_<osclass> -Iプ リフィックスのあるファイル固有のディレクトリで、固有のosク ラスに対するインクルードファイルを検索します

HOST_WARN ホ ストタイプのビルドにコンパイラの警告メッセージが必要ですか? (YESま たはNO) (デ フォルトはYESで す)

CROSS_WARN Cク ロスコンパイラ警告メッセージが必要ですか(YESま たはNO) (デ フォルトはYESで す)

HOST_OPT ホ ストのビルドコンパイラ最適化が必要ですか(デ フォルトはNOで、 最適化なしです)

CROSS_OPT ク ロスコンパイラ最適化が必要ですか(YESま たはNO) (デ フォルトはNOで、 最適化なしです)

CMPLR Cコ ンパイラ選択、TRADANSIま たはSTRICT (デ フォルトはSTRICTで す)

CXXCMPLR C++コ ンパイラ選択、NORMALま たはSTRICT (デ フォルトはSTRICTで す)

リンカのオプション

USR_LDFLAGS リ ンカのオプション(す べてのmakefileの リンク)

USR_LDFLAGS_<osclass> os固 有のリンカオプション(す べてのmakefileの リンク)

USR_LDFLAGS_DEFAULT USR_LDFLAGS_<osclass>を 指定していないシステムのリンカオプション

<name>_LDFLAGS プ ロダクトまたはライブラリ固有のリンカオプション

<name>_LDFLAGS_<osclass> 指 定したosク ラスに対するプロダクトまたはライブラリ固有のリンカオプション

USR_LIBS ラ イブラリのロード(た とえば-lXt -lX11) (す べてのmakefileの リンク)

USR_LIBS_<osclass> ラ イブラリのos固 有のロード(す べてのmakefileの リンク)

USR_LIBS_DEFAULT USR_LIBS_<osclass>を 指定していないシステムのライブラリのロード

<name>_LIBS プ ロダクトまたはライブラリ固有のldラ イブラリ(た とえばprobe_LIBS=X11 Xt)

<name>_LIBS_<osclass> 指 定したプロダクトまたはライブラリにリンクする必要のあるos固 有のライブラリ

<name>_LIBS_DEFAULT <name>_LIBS_<osclass>を 指定していないシステムに対するプロダクトまたはライブラリにリンクする必要のあるライブラリ

PROD_LIBS す べてのシステムに対するPRODに リンクする必要のあるライブラリ

PROD_LIBS_<osclass> ど のPRODに もリンクする必要のあるos固 有のライブラリ

PROD_LIBS_DEFAULT PROD_LIBS_<osclass>を 指定していないシステムに対するPRODに リンクする必要のあるライブラリ

<lib>_DIR 指 定したライブラリを検索するディレクトリ(PROD_LIBS<prod>_LIBSお よびUSR_LIBSに 一覧表示したライブラリ)

SYS_PROD_LIBS す べてのシステムに対するどのPRODに もリンクするのに必要なシステムライブラリ

SYS_PROD_LIBS_<osclass>

ど のPRODに もリンクするのに必要なos固 有のシステムライブラリ

SYS_PROD_LIBS_DEFAULT SYS_PROD_LIBS_<osclass>を 指定していないシステムに対するどのPRODに もリンクするのに必要なシステムライブラリ

<prod>_SYS_LIBS プ ロダクト固有のシステムldラ イブラリ(た とえば m)


org.page#-59

<prod>_SYS_LIBS_<osclass> 指 定したプロダクトにリンクするのに必要なosク ラス固有のシステムライブラリ

<prod>_SYS_LIBS_DEFAULT SYS_PROD_LIBS_<osclass>を 指定していないシステムに対する指定したPRODに リンクするのに必要なシステムライブラリ

STATIC_BUILD ス タティックビルドが必要ですか(YESま たはNO) (デ フォルトはNOで す)win32で は、 STATIC_BUILD=YESの 場合、SHARED_LIBRARIES=NOに 設定します)

インストールするヘッダ ファイル

INC $(INSTALL_DIR)/includeに インストールされるインクルードファイルの一覧

INC_<osclass> $(INSTALL_DIR)/include/os/<osclass>に インストールされるos固 有のインクルードファイル

INC_DEFAULT INC_<osclass>を 指定していない場所にインストールされるインクルードファイル

Perlcshtclなどのスクリプトのインストール

SCRIPTS す べてのシステムにインストールされるスクリプト

SCRIPTS_<osclass> イ ンストールされるos固 有のスクリプト

SCRIPTS_DEFAULT SCRIPTS_<osclass>を 指定していないシステムに対してインストールされるスクリプト

SCRIPTS_IOC iocタ イプアーキテクチャにインストールされるスクリプト

SCRIPTS_IOC_<osclass> iocタ イプアーキテクチャにインストールされるos固 有のスクリプト

SCRIPTS_IOC_DEFAULT SCRIPTS_IOC_<osclass>を 指定していないiocタ イプアーキテクチャにインストールされるスクリプト

SCRIPTS_HOST ホ ストタイプアーキテクチャにインストールされるスクリプト

SCRIPTS_HOST_<osclass> ホ ストタイプアーキテクチャにインストールされるosク ラス固有のスクリプト

SCRIPTS_HOST_DEFAULT

OBJS_HOST_<osclass>を 指定していないホストタイプアーキテクチャにインストールされるスクリプト

TCLLIBNAME $(INSTALL_DIR)/lib/<osclass>に インストールされるtclス クリプトの一覧(Unixホ ストのみ)

TCLINDEX TCLLIBNAMEス クリプトから作成されるtclイ ンデックスファイルの名前

オブジェクトファイル

次のOBJS定 義の名前には、サフィックス(.oま たは.obj)を 加えることはできません。

OBJS す べてのシステムに対してビルドされ、インストールされるオブジェクトファイル

OBJS_<osclass> ビ ルドされ、インストールされるos固 有のオブジェクトファイル

OBJS_DEFAULT OBJS_<osclass>を 指定していないシステムに対してビルドされ、インストールされるオブジェクトファイル

OBJS_IOC iocタ イプアーキテクチャに対してビルドされ、インストールされるオブジェクトファイル

OBJS_IOC_<osclass> iocタ イプアーキテクチャに対してビルドされ、インストールされるos固 有のオブジェクトファイル

OBJS_IOC_DEFAULT

OBJS_IOC_<osclass>を 指定していないiocタ イプアーキテクチャに対してビルドされ、インストールされるオブジェクトファイル


org.page#-60

OBJS_HOST ホ ストタイプアーキテクチャに対してビルドされ、インストールされるオブジェクトファイル

OBJS_HOST_<osclass> ホ ストタイプアーキテクチャに対してビルドされ、インストールされるosク ラス固有のオブジェクトファイル

OBJS_HOST_DEFAULT

OBJS_HOST_<osclass>を 指定していないホストタイプアーキテクチャに対してビルドされ、インストールされるオブジェクトファイル

文書

DOCS $(INSTALL_DIR)/docディ レクトリにインストールされるテキストファイル

HTMLS_DIR ハ イパテキストをインストールするディレクトリ名、たとえば$(INSTALL_DIR)/html/$(HTMLS_DIR)

HTMLS $(INSTALL_DIR)/html/$(HTMLS_DIR)ディ レクトリにインストールされるハイパテキストファイル

TEMPLATES_DIR $(INSTALL_DIR)/templates/$(TEMPLATE_DIR)と して作成されるテンプレートディレクトリ

TEMPLATES $(TEMPLATE_DIR)に インストールされるテンプレートファイル

データベース定義ファイル

DBD bptデー タまたはdbdイ ンクルードによりインストールまたは作成され、$(INSTALL_DBD)に インストールされるデータベース定義ファイルの名前

DBDINC メ ニューまたはレコードデータベース定義およびインストールまたは作成されインストールされるヘッダのサフィックスのない名前

USR_DBDFLAGS dbExpandの オプションフラッグ。パス(-I<path>)と マクロ関数(-S<substitution>)の インクルードだけがサポートされています。

データベースファイル

DB イ ンストールされ、または作成され、$(INSTALL_DB)に インストールされるデータベースファイルの名前

他のプログラムのオプショ ン

YACCOPT yaccの オプション

LEXOPT lexの オプション

SNCFLAGS 状 態記述言語、sncの オプション

<prod>_SNCFLAGSプ ロダクト固有の状態記述言語のオプション

E2DB_FLAGS e2dbの オプション

SCH2EDIF_FLAGS sch2edifの オプション

RANLIBFLAGS ranlibの オプション

Javaプログラムをビルドする環境

JAVA ビ ルドされインストールされるJavaファ イルの名前

TESTJAVA ビ ルドされるJavaファ イルの名前


org.page#-61


JAVAINC O.Commonサ ブディレクトリで作成されるCヘッ ダファイルの名前

JAR ビ ルドされるJarファ イルの名前

JAR_INPUT JARに インクルードされるファイルの名前

JAR_MANIFEST JARの マニフェストファイルの名前

USR_JAVACFLAGS javacツー ルのオプション

USR_JAVAHFLAGS javahツー ルのオプション

Windows 95/NTリソース( .rc)ファイルの環境

RCS ど のPRODLIBRARYを ビルドするのにも必要なリソースファイル(<name>.rc)

RCS_<osclass> iocタ イプアーキテクチャに対するどのPRODLIBRARYを ビルドするのにも必要なリソースファイル(<name>.rc)

RCS_DEFAULT RCS_<osclass>を 指定していないiocタ イプアーキテクチャに対するどのPRODLIBRARYを ビルドするのにも必要なリソースファイル

<name>_RCS 指 定したPRODLIBRARYを ビルドするのに必要なリソースファイル

<name>_RCS_<osclass> 指 定したPRODLIBRARYを ビルドするのに必要なos固 有のリソースファイル

<name>_RCS_DEFAULT RCS_<osclass>を 指定していないiocタ イプアーキテクチャシステムに対して、指定したPRODLIBRARYを ビルドするのに必要なリソースファイル

その他の定義

USR_VPATH ディ レクトリの一覧

BIN_INSTALLS $(INSTALL_BIN)に インストールする指定したディレクトリのファイル(た とえば、BIN_INSTALLS = $(EPICS_BASE_BIN)/aiRecord$(OBJ))

BIN_INSTALLS_<osclass> iocタ イプアーキテクチャのみにインストールする、指定したディレクトリのos固 有のファイル

BIN_INSTALLS_DEFAULT OBJS_IOC_<osclass>を 指定していないiocタ イプアーキテクチャにインストールする、指定したディレクトリのファイル

TARGETS 作 成されてもインストールされないファイル

INSTALL_LOCATION イ ンストールディレクトリ($(TOP)の デフォルト)


4.8 設定ファイル

4.8.1 Base Configureディレクトリ

base/configureディレクトリは、次のディレクトリ構造で構成されて います。

base/

configure/

os/

tools/


org.page#-62

4.8.2 ベース設定ファイルの説明

設定ファイルには定義が含まれ、各種のmakefileにインクルードされるルールをmakeします。

CONFIG.CrossCommon

クロスビルドのすべてのホストとターゲットの定義(ターゲットと異なるホスト)

CONFIG.gnuCommon

gnuコンパイラを使ってビルドするすべてのホス トとターゲットの定義。

CONFIG_ADDONS

<osclass>DEFAULTオプションをもつ変数をセットアップする定 義。

CONFIG_BASE

EPICSベース固有の定義。

CONFIG_BASE_VERSION

EPICSベースのバージョン番号の定義。このファイルは、base/includeにインストールされるepicsVersion.hを作成するのに使います。

CONFIG_COMMON

すべてのビルドに共通の定義。

CONFIG_ENV

EPICS環境変数のデフォルト定義。このファイルは、ComライブラリにインクルードされるenvData.cを作成するのに使います。

CONFIG_SITE

EPICSベースのmake変数を追加または変更するファイル。定義は 通常上書きされます。

CROSS_COMPILER_TARGET_ARCHS =

CONFIG_SITE_ENV

EPICS環境変数のサイト固有定義のデフォルト値。このファ イルは、ComライブラリにインクルードされるenvData.cを作成するのに使います。

CONFIG

すべての他の設定ファイルに対するインクルード宣言。このファイルの最後で、定義を上書きすることにより、他のCONFIG*ファイルの定義を上書きできます。

RELEASE

Tornado IIのような外部プロダクトとEPICSベースのような外部<tops>の場所を指定します。

RULES

このファイルは、ルール設定ファイルをインクルードします

RULES.Db

データベースとデータベース定義ファイルをビルドしてインストールするルール。テンプレートまたはCapFast schematicsまたはその両方から生成されたデータベースをサポートします。

RULES_ARCHS

各ターゲットアーキテクチャに対するターゲットのmakeをビルドできるようにする定義とルール。

RULES_BUILD

Makefilesに対するビルドルール

RULES_DIRS

各サブディレクトリでターゲットのmakeをビルドできるようにする定義とルール。こ のファイルは、ビルドされるサブディレクトリを持つディレクトリでMakefileすることによりインクルードされます。

RULES_JAVA

javaクラスファイルとjava jarファイルをビルドできるようにする定義とルール。

RULES_TOP

uninstalltarのような<top>レベルディレクトリ固有のルールです。RULES_DIRSファイルも含みます。


org.page#-63

4.8.3 ベースのconfigure/osファイルの説明

configure/osディレクトリには、os固有のmake定義があります。このディレクトリのファイルに対し て名前を付けるのはCONFIG.<host>.<target>であり、<host>は指定したホストシステムまたはすべてのサポートし ているホストシステムのCommonアーキテクチャで、<target>は指定したターゲットシステムまたはすべてのサポー トしているターゲットシステムのCommonアーキテクチャです。

た とえば、ファイルCONFIG.Common.vxWorks-pentiumには、vxWorks-pentiumターゲットシステムに対してビルドするとき、すべて のホストシステムでビルドするのに使われるmake定義が含まれます。

さ らに、ホストファイルまたはターゲットファイルのグループに同じmake定義が適用される場合、共通の定義はホストまたは ターゲットファイルにインクルードされる新しいファイルに移動します。このことに対する例は、CONFIG.UnixCommon.Commonファイルに共通の定義があるすべてのUnixホストで、CONFIG.Common.vxWorksCommonで定義されるすべてのvxWorksターゲットです。

base/configure/osディレクトリには、次のos-アーキテクチャ固有の定義があります。


CONFIG.<host>.<target>

固有のホスト-ターゲットビルド定義

CONFIG.Common.<target>

すべてのホストに対する固有のターゲット定義

CONFIG.<host>.Common

すべてのターゲットに対する固有のホスト定義

CONFIG.UnixCommon.Common

Unixホストとすべてのターゲットに対する定義

CONFIG.<host>.vxWorksCommon

すべてのvxターゲットに対する固有のホスト定義

CONFIG_COMPAT

R3.13アーキテクチャ互換の定義

CONFIG_SITE.<host>.<target>

サイト固有のホスト-ターゲット定義

CONFIG_SITE.Common.<target>

すべてのホストに対するサイト固有のターゲット定義

CONFIG_SITE.<host>.Common

すべてのターゲットに対するサイト固有のホスト定義


4.8.4 ベースのconfigure/toolファイルの説明

configure/toolsディレクトリには、ビルドに使われるPerlスクリプトツールがあります。このディレクトリにあ るツールは次のとおりです。

convertRelease.pl

こ のPerlスクリプトは、RELEASEファイルの外部<top>定義の整合性チェックを行い、この外部<top>に対するincludeディレクトリ、binディレクトリおよびlibraryディレクトリの定義を生成します。この定義は、アプ リケーションMakefilesにより使用されるCONFIGファイルにインクルードされます。このスクリプト は、RELEASEファイルの外部<top>定義からRULES_BUILDファイルのインクルード宣言を作成します。

cp.pl

このPerlスクリプトは、コンパイラの警告出力をフィ ルタします。

filterWarnings.pl

ヘッダファイルの依存定義に対するターゲット定義を作成するperlスクリプトです。

installEpics.pl

ビルドしたファイルをインストールディレクトリにインストールするPerlスクリプトです。

makeMakefile.pl

作成したO.<arch>ディレクトリにMakefileを作成するperlスクリプトです。

makeMakefileInclude.pl

このperlスクリプトはMakefilesによりインクルードされるファイルを作成し ます。このファイルにはビルドターゲットの固有定義と依存性が含まれます。

mkdir.pl


org.page#-64

このperlスクリプトは、Unix mkdirコマンドのようにディレクトリを作成します。

mkmf.pl

このperlスクリプトは、ソースファイルインクルード 宣言からターゲットに対するインクルードファイル依存性を作成します。

munch.pl

c++スタティックコンストラクタとデストラクタ の一覧を表示する、vxWorksターゲットアーキテクチャビルドに対するctdt.cファイルを作成するperlスクリプトです。詳細については、vxWorksの文書のmunchingを参照してください。

mv.pl

このperlスクリプトは、既存のファイルの名前を変更 します。

replaceVAR.pl

CapFast生成データベースのVAR(xxx)スタイルマクロをEPICSデータベースで使用する$(xxx)記法に変換するperlスクリプトです。

rm.pl

このperlスクリプトは、既存のファイルを削除しま す。


4.9 ビルド文書 ファイル

4.9.1 Base Documentationディレクトリ

base/documentationディレクトリには、ユーザがepics/baseをセットアップし、ビルドするためのREADMEファイルがあります。

4.9.2 ベース文書ファイルの説明

base/startupディレクトリに格納されているファイルは次のとおり です。

README.1st

epicsベースをセットアップしビルドする説明です

README.html

htmlバージョンのREADME.1st

README.WIN32

Microsoft WIN32に関する説明です

README.niCpu030

NI cpu030に関する説明です

README.darwin

Mac OS X (Darwin)に関する説明です

BuildingR3.13AppsWithR3.14.html

R3.13 vxWorksアプリケーションを変更する方法を説明し、リリースR3.14.1でビルドされています。

ConvertingR3.13AppsToR3.14.html

R3.13 vxWorksアプリケーションに変換する方法を説明し、R3.14 configureディレクトリとR3.14 Makefilesを含み、R3.14.1でビルドしています。

ConvertingR3.14.0alpha2AppsTobeta1.html

R3.14.0アルファ1アプリケーションを変更する方法を説明し、 リリースR3.14.0ベータ1でビルドされています。

ConvertingR3.14.0beta1AppsTobeta2.html

R3.14.0ベータ1アプリケーションを変更する方法を説明し、 リリースR3.14.0ベータ2でビルドされています。

ConvertingR3.14.0beta2AppsToR3.14.1.html

R3.14.0ベータ2アプリケーションを変更する方法を説明し、 リリースR3.14.1でビルドされています。

BuildingR3.13ExtensionsWithR3.14.html

R3.13拡張子を変更する方法を説明し、リリースR3.14.1でビルドされています。

RELEASE_NOTES.html

R3.14.1リリースでの変更を説明します。


org.page#-65

KnownProblems.html

EPICSベースR3.14.1の既知の問題の一覧を示します。

4.10 起動ファイル

4.10.1 Base Startupディレクトリ

base/startupディレクトリには、ユーザが必要な環境変数とパスを 設定し易くするスクリプトが格納されています。EPICSがビルドする前に、適切な起動ファイルを実行しま す。

4.10.2 ベース起動ファイルの説明

base/startupディレクトリに格納されているスクリプトは以下のと おりです。

EpicsHostArch

EPICS_HOST_ARCH環境変数を設定するcシェルスクリプト

EpicsHostArch.pl

EPICS_HOST_ARCH環境変数を設定するperlスクリプト

Site.profile

パスと環境変数を設定するUnix bourneシェルスクリプト

Site.cshrc

パスと環境変数を設定するUnix cシェルスクリプト

borland.bat

パスと環境変数を設定するWIN32のバッチファイル

win32.bat

パスと環境変数を設定するWIN32のバッチファイル


org.page#-66

org.page#-67

5:データベース のロッキング、スキャニングおよびプロセッシング

5.1 概要

IOCソフトウェアの特別なコンポーネントを説明 する前に、3つの関連する内容である、データベースロッ キング、スキャニングおよびプロセッシングの概要を説明します。ロッキングは2つの異なるタスクにより対象としているデー タベースのレコードが同時に変更されないようにします。データベーススキャニングは、レコードを処理するときの決定機構です。

レコードプロセッシングの基本には入力フィールドの現在の値を取得し、出力フィールドに現在の値を出力すること です。レコードが複雑であればあるほど、レコードのプロセッシングも複雑になります。

DATABASEの強力な機能には、レコードが他のレコード にリンクを構成できることがあります。この機能により複雑さが生じます。したがって、ロッキング、スキャニングおよびプロセッシングの前に、レコードのリ ンクを説明します。


5.2 レコードリン ク

データベースレコードには、他のレコードへのリンクがあります。リンクは次のタイプのうちいずれかに該当しま す。

INLINK

OUTLINK

INLINKOUTLINKは、次のうちのいずれかです。

コンスタントリンク

この章では説明しません

デー タベースリンク

同じIOCで他のレコードへのリンク

チャ ネルアクセスリンク

他のIOCで記録するリンク。特別なIOCクライアントタスクを経由してアクセスでき ます。同じIOCでレコードを参照しても、チャネルアクセス リンクに強制的にリンクさせることもできます。

ハー ドウェアリンク

この章では説明しません

FWDLINK

フォワードリンクはレコードを参照し、フォワードリンクを含むレコードが処理されると、レコードも処理されま す。

コ ンスタントリンク

無視

デー タベースリンク

同じIOCの中にある他のレコードへのリンク

チャ ネルアクセスリンク

他のIOCのレコードへのリンクまたはチャネルアクセ スリンクへの強制的なリンク。リンクがPROCフィールドを参照しない限り、無視されま す。PROCフィールドを参照する場合、チャネルアクセ スで1の値が発生します。


org.page#-68

リンクはファイルlink.hで定義されます。

注:この章では主にデータベースリンクにつ いて説明します。


5.3 データベース リンク

データベースリンクは、次のルーチンの一つを呼び出すことにより参照されます。

dbGetLink:入力リンクにより参照されるフィールドの値が読み込 まれます。

dbPutLink:出力リンクにより参照されるフィールドの値が変更さ れます。

dbScanPassive:フォワードリンクにより参照されるレコードは、受動 である場合に処理されます。

フォワードリンクは、受動レコードを参照して処理するとき、リンクを含むレコードを処理するときに、意味を持ち ます。入力リンクと出力リンクに対して、アプリケーション開発者が、受動プロセスと重要度の最大化の2種類の属性を指定できます。


5.3.1 受動プロセス

受 動プロセス(PPまたはNPP)は、TRUEまたはFALSEのいずれかの状態をとります。リンクされたレコード が入力リンクから値を取得する前か、出力リンクに対して値を書き出した後に処理を行うかを決定します。レコードが受動レコードで受動プロセスがTRUEの場合に限り、リンクされたレコードはdbProcessへの呼び出しを経由して処理されます。

注:その他の3種類のオプションは、CACPおよびCPPで指定されます。このオプションはリンクを チャネルアクセスリンクのように強制的に取り扱います。詳細については、このセクションの最後の部分を参照してください。


5.3.2 重要度の最大化

重 要度の最大化(MSまたはNMS)は、 TRUEまたはFALSEで す。アラームの重要度がリンクを経由して伝播するかどうか決定します。入力リンクでは、リンクが参照するレコードのアラーム重要度は、リンクを含むレコー ドに伝播します。出力リンクでは、リンクを含むレコードのアラーム重要度は、リンクが参照するレコードに伝播します。いずれの場合でも、重要度が変化する と、アラーム状態はLINK_ALARMに設定されます。

ア ラーム状態と重要度を変更するかどうか決定する方法は、”重要度の最大化”と呼ばれます。実際の状態と重要度に 加えて、レコードには新しい状態と重要度が割り振られます。新しい状態と重要度の初期値は0で、NO_ALARMを 意味します。ソフトウェアコンポーネントが状態と重要度を変更するときには、最初に新しい重要度を確認し、設定する常用度が現在の重要度の値より大きい場 合、変更が行われます。変更を行った場合、現在の状態と重要度ではなく、新しい状態と新しい重要度を変更します。レコード処理ルーチンで通常行うデータ ベースを確認したとき、現在の状態と重要度は新しい値と等しくなり、新しい値はゼロにリセットされます。最終的な結果は、現在のアラーム状態と重要度が、 最高の重要度アラームを反映します。同じ重要度のアラームが複数ある場合、最初の状態が削除されて状態が反映されます。


5.4 データベース ロッキング

デー タベースロッキングの目的は、2つの異なるタスクによりレコードが同時に処理されな いようにすることです。これに加え、レコードが処理されている間に”外部”のタスクがフィールドを変更しないよ うにします。

データベースロッキングには、次のルーチンがあります。

dbScanLock(precord);


org.page#-69

dbScanUnlock(precord);

基 本的な考え方として、データベースレコードにアクセスする前にdbScanLockを呼び出し、後でdbScanUnlockを呼び出します。

デー タベースリンク(入力、出力および転送)のため、1つのレコードへの変更は、他のレコードの変更も生じ ます。リンクし合うレコードは、同じロック状態になります。dbScanLockは、リクエストしたレコードだけでなく全体のロック 設定を決定します。dbScanUnLockは、全体の設定のロックを解除します。

次の規則により、ロックルーチンを呼び出す時期を決定します。

1. 周期的、I/Oイベントおよび処理の前にイベントタスクがロック し、処理の後にロックを解除します。

2. dbPutFieldレコードを変更する前にロックし、後でロックを解除 します。

3. dbGetField読み込む前にロックし、後でロックを解除します。

4. 非同期レコードサポート完了ルーチンは、レコードの 変更前にロックし、後でロックを解除する必要があります。

OUTLINKsFWDLINKsを経由してリンクするすべてのレコードは同じロック 条件となります。process_passiveまたはmaximize_severity TRUEであるINLINKを経由してリンクするレコードは、強制的に同じロッ ク条件になります。


5.5 データベース スキャニング

データベーススキャニングはデータベースのレコードを処理するリクエストです。4種類のスキャニング方法があります。

1. Periodic - 周期的にレコードのスキャンが行われます。

2. I/O event - I/O割り込みの結果としてレコードのスキャンが行われま す。

3. Event - post_eventリクエストを発するタスクの結果としてレコードのス キャンが行われます。

4. Passive - dbScanPassiveを呼び出した結果としてレコードのスキャンが行われ ます。レコードが受動で処理が行われていない場合に、dbScanPassive