CMakeとMakeについての調査

課題背景：

多数のソース・ファイルからビルドされるようなプロジェクトは結構あります。 それをデバッグする時、毎回全てのソース・ファイルをコンパイルしているとデバッグに時間がかかってどうしようもありません。（プロジェクトによってはビルドに１時間かかるようなものもそれなりにあります。） それは避けたいので、修正したソース・ファイルだけコンパイルし、他のものは前回コンパイルした結果を使ってプロジェクトをビルドするのが一般的です。 コマンドの実行手順を自動化する手段といえば、真っ先にシェルスクリプトを思い浮かべる人も多いでしょう。 そもそもmakeなどのビルドツールは、インストールするユーザーだけが利用するものではありません。ソフトウェア開発者も開発中に利用するものです。 ソフトウェアの開発中は、何度も繰り返しビルドを実行しますし、開発が進むにつれてビルド手順が増えることもあります。手順を書き換える必要に迫られることもあります。 このような状況で開発者が求めるのは、単に手順通りビルドできればよい、というツールではありません。ビルド手順を簡潔に表すことができて、高速にビルドできるツールが必要なのです。さらにはOSなどのプラットフォーム間の互換性を維持したいということもあります。ビルドツールはそういった期待に応えるべく設計されているのです。

解決ツール：

ninjaとは、高速な動作を重視した小さなビルドシステムである。より高レベルなビルドシステムによってビルドファイルを生成するように設定されている点と、可能な限りビルトを高速に行うように設計されている点が他のビルドシステムと大きく異なる点である。
本質的に、ninjaはMakeの置き換えを意図している。Makeは増分ビルドまたはリビルトをした場合は低速である。Google ChromeはNinjaの主要なユーザーであり。
CMakeとMesonは、Ninjaのビルドファイルの生成に対応した著名なビルド管理ソフトウェアである[7]。

ninjaの特徴：
・並列ビルド(複数のCPUで同時にビルド)ができる
・差分ビルド(変更のあったファイルだけをビルド)ができる

ningjaファイルの作成手順（pythonはコンバータの作成とninjaスクリプトを生成するのに使用します）

pythonでコンバーターの準備(ソースをまとめるみたいな役割だと思いますが、詳しくわかりません)

　　　　　　　　　　　⇩
　　　　　pythonでninjaファイルを生成する

ninjaにはincludeで別ファイルを読み込む機能があるので３つにファイルを分割しました。

①config.ninja (ビルドで共通で使用する変数を定義)
②rule.ninja (コンバーターの呼び出しルールを記述)
③build.ninja (本体。コンバートするファイルを列挙)

小さいプロジェクトなら一つでも十分だと思います。

リソースビルドを作るうえで最も注意しなければならないのはビルドの依存関係です。依存関係を適切にninjaに伝えることでこのコンバートのあとこのコンバートを実行するだとかこのファイルが変更されたらこのコンバートを実行する等が正しく行われます。

makeとは
makeは、主として、C言語やC++などコンパイル型のプログラミング言語で記述されたプログラムを容易にビルドするためのツールです。
make make

The purpose of the make utility is to determine automatically which pieces of a large program need to be recompiled, and issue >the commands to recompile them.
makeは大規模プログラムのどの部分を再コンパイルするべきか自動的に決め、それらをコンパイルするコマンドを実行するためのもの。

Cmakeとは、CMakeはC, C++, CUDA, Fortran, assemblerなどのプロジェクトのビルドをコンパイラに依存せず自動化するためのツールです。
CMakeでは、CMakeLists.txtという設定ファイルを作成しておけば、そこからCMakeがサポートする任意のプロジェクトファイルを作成することができます。 つまり、どの開発環境でもプロジェクトをビルドできるようになります。それゆえ、CMakeはクロスプラットフォームなC++プロジェクトを開発するために欠かせないツールとなっています
CMakeLists.txtをはじめとするCMakeの各種設定ファイルは、独自の手続き型のスクリプトを使って記述します。 このスクリプトには変数や関数の概念があり、雰囲気はshellスクリプトに近いです。
CMakeではビルドの前にConfigure, Generateという2つの作業を行います。
Configureとは、先ほど書いたCMakeLists.txtをCMakeに実行させてビルドに必要な情報を収集する作業のことです。
Generateは、Configureで集めた情報を基に自分の開発環境に合わせたプロジェクトファイルを生成する作業です。CMake ..\ Generatorを明示的に指定したい場合はcmake .. -G ”Visual Studio 16 2019″や`cmake .. -G "Xcode"のようにオプションを追加しましょう。
Generatorの一覧はcmake –helpで確認できます。 なお、CMakeのオプションは指定子の後のスペースを省略できるので、-G Xcodeと-GXcodeはどちらも正しく動きます。
./configure コマンド実行後、以下のように「Configuring done」「Generating done」の文字が表示されていれば成功です。
これで、buildディレクトリの中にMakefile, .sln, .xcodeprojなどのプロジェクトファイルとその他の必要なファイルが生成されているはずです。
makeコマンドの前に実行している./configureコマンドが、Makefileを生成
(MakeFileの生成にはmakeとcmakeのやり方が違います、
makeの場合では、./configureでMakeFileを生成する、
CMakeの場合では、 CMakelists.txtの設定を行ったうえで、
　カレントディレクトリはbuildでcmake .. を実行する。⇦　これはジェネレータが暗黙的に指定するコマンドです。
　ジェネレータを明示的に指定する場合はcmake .. -G”Visual Studio 16 2019″やcmake .. -GXcode を使います。　)

./configure
checking for a BSD-compatible install… /usr/bin/install -c
checking whether build environment is sane… yes
checking for a thread-safe mkdir -p… /bin/mkdir -p
checking for gawk… gawk
checking whether make sets $(MAKE)… yes
checking for gcc… gcc
checking whether the C compiler works… yes
checking for C compiler default output file name… a.out
checking for suffix of executables…
checking whether we are using the GNU C compiler… yes
checking whether gcc accepts -g… yes
checking for gcc option to accept ISO C89… none needed
checking for style of include used by make… GNU
checking dependency style of gcc… gcc3
checking for ranlib… ranlib
（略）
checking where the gettext function comes from… libc
configure: creating ./config.status
config.status: creating Makefile
config.status: creating contrib/Makefile
config.status: creating doc/Makefile
config.status: creating gnulib/lib/Makefile
config.status: creating man/Makefile
config.status: creating po/Makefile.in
config.status: creating src/Makefile
config.status: creating tests/Makefile
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing po-directories commands
config.status: creating po/POTFILES
config.status: creating po/Makefile

あとは作成されたプロジェクトファイルを使ってビルドするだけです。 cmake –build .を実行

Cmake Generatorの役割とは A CMake Generator is responsible for writing the input files for a native build system.

ジェネレータとは何ですか？

ジェネレータとは何かを理解するには、まずビルドシステムとは何かを調べる必要があります。 CMakeはソースファイルをコンパイルまたはリンクしません。 generatorを使用してビルドシステムの構成ファイルを作成しました。ビルドシステムは、これらのファイルを使用して、ソースコードファイルをコンパイルおよびリンクします。

それでは、ビルドシステムとは何ですか？ ビルドシステムは、一般にソースコードのコンパイルとリンクに使用される一連のツールをグループ化した広義の用語ですが、ビルドプロセス中に使用される補助ツールを含めることもできます。

cmakeファイルの役割とは cmakeファイルとはcmakeシェルスクリプトファイルのことです。 普段使用している CMake ファイルCMakeLists.txtはcmake .によって実行し、Makefileなどのビルドシステムを生成するために使用していました。これに対してhoge.cmakeといったスクリプトファイルはcmakeコマンドに-Pオプションを付与してcmake -P hoge.cmakeといった形で利用します このスクリプトファイルは、ビルドシステムの生成に特化したものではなく、シェルスクリプトのように汎用的に使用することができます。 ビルド・システム生成は、CMakeLists.txtというファイルに設定します。（１つのフォルダに１つしか存在する必要がないため、このファイル名は変更できません。） スクリプト・モード用のスクリプト・ファイルは１つのフォルダの配下に複数用意することがあるので名前を自由に付けることができます。拡張子は.cmakeに決っているようです。（他の拡張子を付けても呼び出せますが、慣習に従って.cmakeにしておいたほうが良いと思います。）

makeとCMakeの違いについて

Cmakeの便利なところ
①out-of-sourceビルド()

②クロスコンパイル用設定の分離(後述)

③autotoolsに比べ必要なファイルが少ない(CMakeList.txtを一つ置くだけで良くなる)

④設定ファイルはCMakeLists.txtになります。

⑤静的ライブラリを作成

⑥共有ライブラリを作成

Makeの便利なところ
①クロスビルドができる

②MakeFile に依存関係を書き，make で MakeFile のコマンドを実行してくれるやつみたい

差分をコンパイルしてくれるらしくてすごい賢い子みたい．

③設定ファイルはMakeFileになります

out-of-source build とは、プロジェクトのビルドディレクトリをソースディレクトリと別に作成する手法。 中間ファイルや生成物が整理されるため、プロジェクトの管理が楽になる。

Makefileとは

makeにはビルドに関する情報を格納した設定ファイルが必要です、これは、Makefileというファイル名がデフォルトになっています。
makeコマンドは、コンパイル作業を行うために様々な作業を自動的に行うためのコマンドです。「Makefile」は、コンパイル、依存関係の管理、インストールなどのルールを記述しておくためのファイルで makeコマンドが読み込んで処理を行います。Makefileには、ファイルの生成手順や、プログラムを構成しているファイル同士の関係を記述します。

ビルドとコンパイルの違いについて、ビルドはコンパイルのプラスアルファです。または、ビルドの中にコンパイルがある。
ソースコードを機械語に翻訳する作業がコンパイルです、または、ソースコードをオブジェクトコードに変換すること
ビルドとは、ソースコードのコンパイルやライブラリのリンクなどを行い、最終的な実行可能ファイルを作成すること。
また、そのような作業によって生成されたソフトウェアの版。

Makefileは、configureスクリプトを実行することにより、システム
に合ったものが自動的に生成されます。
ソースからソフトウェアをインストールする手順を覚えておきましょう。

(1) tarコマンドでアーカイブを展開

(2) configureスクリプトを実行してMakefileを生成

(3) makeコマンドでコンパイル

(4) make installコマンドで実行ファイルなどをインストール

纏め

CMake と　makeはビルドツールです(またはビルドマネジメントツールといいます)。

ninjaはビルドシステムです。

MakeFileはmakeの設定ファイルです。

CMakeLists.txtはCMakeの設定ファイルです。

CMakeを用いてコンパイルする時の設定ファイルが、CMakeLists.txtです。cmakeコマンドを実行すると、この設定ファイルに従って、各OSに対応したMakefileが生成される仕組みになっています。

cmakeファイルはCMakeのシェルスクリプト

参考サイト

1

2

3

4

UbuntuでSSDマウント手順

手順

  1. ssdをpcに取り付ける、sudo fdisk -lでデバイスを確認

  2. ssdをlinuxファイルシステムにフォーマットする、mkfs -t ext4 /dev/sdbでフォーマットする

  3. ssdをPCにマウントするディレクリを予めに用意する、mkdir /mnt/ssd でディレクトリを作成する。

  4. ssdを先に作ったディレクトリにマウントする、 mount /dev/sdb /mnt/sdbでssdをマウントする.

  5. 最後にマウントしたデバイスを確認する、　mountでssdがマウントされたかを確認する. 自動マウント設定 sudo blkidでssdのuuidを確認する。uuidをメモする。 sudo vim /etc/fstab で下記のようにの一行を追加する。

UUID=18b007ff-0102-4a7c-a05d-*********** /mnt/ssd ext4 defaults 0 0

以上ubuntuでssdをマウントする作業が完了。

プロセスとスレッドの違いについて

  • プロセスとは、アプリケーションのリソースを保持する機能とアプリケーションの命令を実行する機能を持っている。

  • プロセス間は同じプロセスを使用していない限りはメモリを共有しません。 それぞれ個別にリソースの割り当てが行われる。

  • スレッドに比べるとプロセス間の切り替えはメモリの切り替えを伴うため、処理スピードが遅くなる。プロセス同士は独立性を持つ、一つダメになっても、ほかのプロセスはそのまま実行を続ける。

  • スレッドとはプロセス内に作られる並列処理を行うための仕組みです。処理の単位です。

  • スレッドはプロセスに割り当てられたメモリを使用して動作する。

  • スレッド同士では、 メモリを共有している為、メモリの切り替えも含めたプロセスの切り替えに比べると、スレッドの切り替えは高速に動く。

  • 同じ変数に対してスレッド同士が同時に値を書き換えようとする場合に開発者が移動していない状況になる、このような問題に起らないため、スレッドセーフを意識する必要あり。

  • cpuは1コアに対して一度に1のプロセスしか実行できません、マルチプロセスを実現するには、マルチプロセス機能によって、複数のプロセスを細かく切り替えることで、同時に動いているように見せているのです。

プロセス(タスク)　⇒　スレッド　の関係

Ubuntu プロキシサーバの構築(Ubuntu 14.04)

  • pcにインストールしたソフトウェアを最新バージョンにアプグレッドする、sudo apt-get update && sudo apt-get upgrade

  • squidをインストール　sudo apt install squid

  • プロキシサーバの設定を行う

  • squid.confのバックアップをつくる、　sudo cp /etc/squid3/squid.conf /etc/squid3/squid.conf.original

  • コンフィグファイルを編集する、 sudo vim /etc/squid3/squid.conf

  • http_portとhttp_accessを修正する、　vimでは/を使ってファイルの上から検索していく、nを押して次の検索項目にカーソルを移す。

  • http_port=8888(デフォルトは3218)、http_access allow all を追加して、すべてのIPからプロキシサーバーに接続できるように設定する。

  • sudo service squid3 restartを実行して、プロキシサーバを立ち上げる。

  • ブラウザからプロキシサーバ経由でインタネットに接続するように設定して(インタネット設定のプロキシ設定を行う)。ブラウザで好きなサイトページを開いてみて。

  • sudo tail -f /var/log/squid3/access.logを実行して、プロキシサーバ経由でアクセスしたクライアントを確認できます。

Linuxディレクリの役割について

  • /bin :一般ユーザに向けの基本コマンド

  • /etc :設定ファイル

  • /var :システムログなど動的に変化するファイル(ログファイルやメールボックスなどの置き場)

参考サイト：

Install Squid Proxy Server On Ubuntu14.04

Basic Authentication

Apacheディレクトリインデックス設定

トラブル発生の背景

自作ローカルサーバのDocumentRootの中では、index.htmlとindex.php(cgiの役割を果たすためのphp)ファイル両方が存在する時、かつ、クライアント側では、サーバにアクセスファイル名を指定しない場合、システムが正常に動作しない場合があります(私の場合だと、404エラーが発生してしまいます)。

※DocumentRootとは、クライアントからサーバにアクセスできるディレクトリのことです。

トラブル発生の原因分析

クライアントからリクエストがあった時、ファイル名を指定せずにディレクトリだけ指定された時があります。そのようなファイル名が省略された場合にどのファイルを返すのかを「DirectoryIndex」で指定します。

DirectoryIndex ファイル名　ファイル名　.... ※ファイル名は1つまたは複数指定することが可能です。

さて、デフォル状態でディレクトリインデックスの設定はどうなっているのかを調べるために、httpd.confで「DirectoryIndex」を検索します。私のapacheサーバでは下記のようなデフォル設定になっています。

<IfModule dir_module>
   DirectoryIndex index.php index.pl index.cgi index.asp index.shtml index.html index.htm \
                  default.php default.pl default.cgi default.asp default.shtml default.html default.htm \
                　home.php home.pl home.cgi home.asp home.shtml home.html home.htm
 
</IfModule>

上記のデフォルト設定では、クライアント側で「http://localhost/」を入力したら、サーバのほうでは、「index.php」「index.pl」「index.cgi」「index.asp」などを順番にDocumentRootでファイルを検索していく、見つかれば、そのファイルをクライアントに返す。もしDocumentRootディレクトリの下に、「index.php」「index.html」両方が存在する場合だとしたら、クライアント側に返すのは「index.html」ではなく「index.php」です。

トラブル解決方法

クライアントが「http://localhost」で入力したら、「index.html」にアクセスしてほしいので、httpd.confのDirectoryIndexが下記のように修正します。

<IfModule dir_module>
   DirectoryIndex  index.html 
</IfModule>

参考サイド:

  1. ディレクトリインデックス(DirectoryIndex)

  2. Apache VirtualHost Setting Up

Apache setting [cancel deflate module] in ubuntu14.04

  • Check if mod_deflate is installed and enabled run the command below

apachectl -t -D DUMP_MODULES |grep deflate

if your apache server installed mod_deflate and enabled it, you will see

deflate_module (shared)

Configuration

  • comment out lines that you think it is unnecessary to compress in the file deflate.conf (which is located in /etc/apache2/mods-available in ubuntu14.04) such as my setting
<IfModule mod_deflate.c>
    <IfModule mod_filter.c>
    # these are known to be safe with MSIE 6
    #AddOutputFilterByType DEFLATE text/html text/plain text/xml
     
    # everything else may cause problems with MSIE 6
    #AddOutputFilterByType DEFLATE text/css
    #AddOutputFilterByType DEFLATE application/x-javascript application/javascript application/ecmascript
    #AddOutputFilterByType DEFLATE application/rss+xml
    #AddOutputFilterByType DEFLATE application/xml> 
    </IfModule>
</IfModule>

sudo service apache2 restart

Refer to the following Link

Refer to the following Link

Apache でBasic Authentication設定方法(Windows版)

Xampp での設定方法を紹介します

ベーシック認証とは

.htaccessを使ってパスワードをかけます。.htaccessを設置したフォルダ以下のファイルへアクセスさせません、シンプルですが強力なセキュリティです。 つまり、Virtual-Hostで設定したドキュメントルートにあるディレクトリーに「.htaccess」というファイルを作成して、ベーシック認証の設定を行う

.htaccessの中身を設定

AuthUserfile c:\xampp\etc.htpasswd
AuthGroupfile /dev/null
AuthName “Enter your ID and PW”
AuthType Basic
require valid-user

上記各項目の意味合いを説明

  • AuthUserfileとはログインするユーザのIDとパスワードを書いたファイルの場所を記載する。(絶対パスで記入してください)

  • AuthGroupFileとはログインするグループのIDとパスワードを書いたファイルの場所を記載する(ここでは/dev/nullで設定する、グループIDは使わないないので、指定しないの意味です。)

  • Authnameとはパスワードをかける領域名です。つまり認証ダイアログボックスのタイトルを設定する

  • Authtypeとは認証方式です。

  • require valid-userとは認証されたすべてユーザのアクセスを許可するという意味です。

上記の.htaccessで設定した.htpasswdファイルを生成する方法

  • windowsユーザなので、スタートメニューの検索欄で「cmd.exe」を入力し、実行 または「windowsボタン」＋「R」キーを押下で、「cmd.exe」を入力し、「OK」をクリック コマンドプロンプトを起動したら、下記コマンドを実行し、.htpasswdファイルを作成

c:\xampp\apache\bin\htpasswd -c c:\xampp\etc\.htpasswd user_name

※その他

※etcフォルダがなければ、予めに作成しておいてください。

※user_nameは自分の作りたいユーザの名前に置き換えてください

万が一自分が作成したユーザのパスワードを忘れた場合、下記のコマンドを実行して新しいパスワードを発行できる

c:\xampp\apache\bin\htpasswd c:\xampp\etc\.htpasswd user_name

※user_nameはパスワードを忘れたユーザの名前に置き換える