cmake で framework を生成する
この前の記事で、cmake のプロジェクトで cocoa の framework を作成するオプションを見つけたので試してみる。

framework の生成
必ずしも info.plist は必須ではないようだ。
サンプルのうち、以下のように info.plist と CODE_SIGN の部分を潰しても framework は生成される。
CMakeLists.txt
cmake_minimum_required(VERSION 3.13)
project(TestFramework C)
add_libraryFr(TestFamework SHARED
TestFramework.h
TestFramework.c)
set_target_properties(TestFramework PROPERTIES
FRAMEWORK TRUE
FRAMEWORK_VERSION C
MACOSX_FRAMEWORK_IDENTIFIER com.akiba.TestFramework
#MACOSX_FRAMEWORK_INFO_PLIST ${CMAKE_CURRENT_SOURCE_DIR}/Info.plist
# "current version" in semantic format in Mach-O binary file
#VERSION 16.4.0
# "compatibility version" in semantic format in Mach-O binary file
#SOVERSION 1.0.0
PUBLIC_HEADER TestFramework.h
#XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "Developer ID Application: Taro Akiba(123xxx789)"
)
この状態で
cmake -S . -B build
としても Makefile は生成される。もちろん make で TestFramework.framework も生成される。生成するだけならば
FRAMEWORK TRUE
とするだけでいいようだ。
生成された framework を使ってみる
とりあえずお試しなので TestFramework.h と TestFramework.c は以下のような簡単なものにした。
TestFramework.h
#ifndef TESTFRAMEWORK_H
#define TESTFRAMEWORK_H
int twice(int);
#endif
TestFramework.c
#include <stdio.h>
#include "TestFramework.h"
int twice(int n) {
return 2*n;
}
これで、cmake を走らせると確かに TestFramework.framework はできている。
次に Xcode で別のプロジェクトを作成して TestFramework.framework を取り込む。
main.m から以下のように使う。
#import <Foundation/Foundation.h>
#import <TestFramework/TestFramework.h>
int main(int argc, const char * argv[]) {
NSLog(@"%2d",twice(3));
return 0;
}
走らせてみると・・

予想通り 6 と表示してくれました。
成功、成功。
rpath の設定
なお、設定にもよるのだが、こうして作成されたコマンドラインプログラムを(Xcode 上ではなくて)ターミナルから実行すると
Library not loaded: @rpath
というエラーが出る時がある。
このエラーは、コンパイル時の @rpath の設定が実際に生成されたプログラムが参照すべきライブラリ(今回は TestFramework)の path と一致していない時に発生する。
その場合は、Xcode の Runpath Search Paths あたりの設定を見直してください。

ここ、指定しておかないと framework の所定の置き場所しか見に行かないようです。
正しく設定できていれば、ターミナル上からも
と Xcode 環境で走らせた時と同様の結果になります。
Xcode -aggeragate target-
ところで、であるが、アイキャッチの赤い三重丸のようなやつの正式名称を知っているだろうか?
aggeregate target
どことなく射的の的を連想させるアイコン(ターゲット)は aggeregate というらしい。
英単語としての発音は「アーグリゲイト」、一般的な意味は「集約する、合計する」だ。
日本語の情報はほとんどなく
『ライブラリ・SDKにSwiftLintを導入するベストプラクティス』
でかろうじて触れられているのみ。
aggregate target を生成するのもややクセがあって、
File -> New -> Target…
として(↓)、

ダイアログを表示させ iOS や macOS ではなく other の方を選ぶ。
これは調べないと分かりませんね。
参考
その他、Xcode やビルドシステムについて。
・cmake 単体で iOS のプロジェクトを取り扱う。
『cmakeを使ってxcodeを使わずにiosアプリを作成する』
・cmake で Xcode のプロジェクトファイルを生成する。
help によれば cmake で framework を直接生成できるらしいのだが、試したことはない。
(→結局、試しました)

余談 -External Build System-
ところで、アーグリゲイトなターゲットを作成する際、こういう画面が出てくる。

気になるのは External Build Sysytem だと思うが、イマイチ使い方がわからない。
デフォルトだと make を使うように設定されているのだが、aggregate ターゲットでもいけるはずだが???
余裕があったら、調べます。
余談 Xcode での C++ 標準ライブラリのヘッダーファイルの置き場所
Xcode14 では
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1
です。
よく移動になるみたいですね。
標準ライブラリのヘッダーファイルが見つからない場合は、上のフォルダを header search paths に設定する。
OpenJPEG を使ってみる
他のライブラリに組み込まれて使われることの多い OpenJPEG というライブラリだが、opj_compress や opj_decompress というコマンドラインツールもあるらしい。
さあ、これを使おうと思ったのだが、インストール時にやらかしていたようです…orz

これは再インストールですな。
libpng について
普通にインストールすれば(↓)、png.framework はできないはずだが、はて?

おそらく、インストールの過程のどこかで png.framework を生成していたんでしょう。
ところで libpng にもコマンドラインツールがあるようだ。
興味がある方は、ターミナルから libpng16-config とタイプしてください。
再インストール
libpng → OpenJPEG の順にインスコ。
再度、コマンドラインツールを呼び出すと…
% opj_decompress -h
This is the opj_decompress utility from the OpenJPEG project.
It decompresses JPEG 2000 codestreams to various image formats.
It has been compiled against openjp2 library v2.5.0.
Parameters:
-----------
-ImgDir <directory>
Image file Directory path
-OutFor <PBM|PGM|PPM|PNM|PAM|PGX|PNG|BMP|TIF|TIFF|RAW|YUV|RAWL|TGA>
REQUIRED only if -ImgDir is used
Output format for decompressed images.
今度は、正常に起動。
テスト
テストコマンドが使えるようになったので、png ファイルで圧縮・伸展を試してみる。
今回は特にオプションをいじらず、ノーマルのまま。
結果は以下のようになった。

ちょっと色目が濃くなっている感じでしょうか。
医療画像
ところで、JPEG 2000 は当初の想定よりは普及している感じはしないが(それでも MacOS では標準でサポートされている)、医療画像の世界では広く使われているようだ。
この記事内で
日頃お世話になっている DCMTK だが、JPEG2000 系は(オープンソース版)では基本的にはサポート外だ。
内部的には OpenJPEG 組み込んでいるはずなんですけどね(すっとぼけ)。
と言及されている。
DCMTK と OpenJPEG の橋渡しは、いろいろな方法が考えられると思うが(上の例のように OpenJPEG のアプリで圧縮・展開ができているのだから、これを組み込んだソフトでできないはずがない)、自分で繋ぎのコードを書いてもいいし、このプロジェクトを使ってもいいだろう。
後者のプロジェクトは CMake の書き方があまりいいものではないので、MacOS なら .xcodeproj を生成させてからビルドするといいと思う。
覚え書きとものぐさ
プログラミング関係の記事が増えてきた。
読み返すとタイトルに「ものぐさ」あるいは「覚え書き」とついているものが多い。
今まで厳密に使い分けてきたわけではなかったが、
ものぐさ・・通常、難解とされているところを肩に力が抜けた感じで、さらっと書く
覚え書き・・基本的なことをある程度実用的にまとめる
というような傾向があるようだ。
今後はこの方針である程度意識的にタイトルつけていきやす。
