I've modified GNU Make to support strict dependency checking. This is all thanks to the Landlock LSM system calls which were introduced in Linux Kernel 5.13 twelve months ago. What it means is that Make can now solve the cache invalidation problem similar to Bazel except with 5x better performance. Background I blogged last month about our work porting OpenBSD pledge() and unveil() to Linux as par
Go言語開発での makeコマンド と Makefile Go言語の開発ではmakeコマンドをタスク自動化ツールとしてよく使います。 よく使うコマンド、自動化したいタスクをMakefileに記述しておくと、開発に使う複雑なコマンドをすぐに実行したり、チームで共有出来ます。 Makefileに対して、難しいイメージを持っているかもしれませんが、超基本のMakefileの書き方はとてもシンプルなものです。 この記事の目的 Makefileの超基本がわかる Go言語開発のタスク自動化ツールとしてのMakefileの書き方がわかる 前提知識 シェルスクリプト についての知識 書き始める前の準備 EditorConfigを設定して、タブ / スペース によるインデントのトラブルに会わないようにしましょう。 公式サイトにあなたのエディタが、EditorConfigをサポートしているか、プラグインの追加
去年の春に「そろそろスーファミのプログラム書いてみてえな」と思い立って スーパーファミコンのプログラムを書きたい - ポルノアニメ ということがあったんですが、あれから約1年半。自分なりの開発環境が固まってきて、簡単なゲームぐらいなら流れ作業的に作れる程度まで圧倒的成長したので、ここで一度、我が家のスーファミ開発環境をまとめて紹介します。 OSとPC 普通のWindows PCでよい。 make 元気よくcygwinをインストールしよう。 Windows 10でUbuntuが動くやつは私の見聞きした情報が正しければ、何の役にも立ちません。 アセンブラ cc65/ca65 というものを使っている。名前を見るとCで書けそうだけど、それは6502(初代ファミコン)用のコードだけで、65816のコードはアセンブリで書く必要がある。つまり実際に使うのはca65の方だけ。 スーファミには、メインCPU
SREチームの@cubicdaiyaです。今回はDockerとMakeを利用したメルカリの自作RPMパッケージのビルド環境について紹介します。 メルカリの自作RPMパッケージ事情とVagrant、そしてDocker メルカリの開発およびプロダクション環境では現在CentOS6と7を利用しており、随時CentOS7へ移行中です。そのため、自作RPMパッケージをビルドする際はCentOS6と7向けにそれぞれビルドしています。ビルドしたパッケージはyumリポジトリサーバにアップロードした後、必要に応じてyumでインストール、Ansibleのplaybook化を行います。 RPMパッケージの作成はSREチームのメンバーが行っており、各自のローカルマシン上において make {パッケージ名} を実行するだけでCentOS6と7向けのRPMパッケージをビルドできる環境をDockerで構築しています。
CentOS 6.2 に Open vSwitch をインストールする手順について。 rpm 化したほうが入れたり消したりが便利なので、全て rpm でのインストールです。 要点 KVM + libvirtd での仮想化環境のホスト側仮想スイッチとして、デフォルトの Linux bridge の置き換えが目的 すでにbridge構成なネットワークになっている仮想化環境を想定 全部 rpm でインストールする ざっくりとこんな流れ 2.64 以降の autoconf をインストール Open vSwitch のビルドに必要なその他パッケージ(kernel-devel openssl-devel)をインストール Open vSwitch のrpmを作成、インストール Open vSwitch の設定 autoconf 2.68 を rpm でインストール まず Open vSwitch のビル
しばしば見落とされがちですが, Makefileは立派な(=チューリング完全な)プログラミング言語です. GNU Make, 3rd Edition([1], 以降make本と記します)をパラパラしながら読み終わりました. 最後の最後で, Makefileの中で「数字の計算をする方法」が書いてあり, あ, こりゃ, 僕がやるしか無いな, と思ってこのエントリーを書きました. GNU Make 第3版 作者:Robert Mecklenburg発売日: 2005/12/01メディア: 大型本 基本事項 Makefileの基本事項です. と言っても, 暗黙のルールとかマニアックな特殊ターゲットとかは今の僕にはあまり興味が無いです. まず, Makefileをビシビシ書くにあたって, デバッグのために簡単に出力する方法を知って置かなければなりません. warning関数を使います. make本1
golang (for Windows) でクロスコンパイルする際にハマったポイントと、 解決方法を紹介します。 TL;DR golang のクロスコンパイルを準備する場合には、以下の点に留意してください。 (Windows のみ) gccは32ビット版か64ビット版か、使いたい方を正しく選択する 2つ以上の環境へクロスコンパイルする場合には、make.bat/make.bash 実行時に --no-clean を指定する クロスコンパイルの準備をする golang を用いるとクロスコンパイルが容易なことはよく知られています。例えば、Windows上のgolangであっても、OSX向けのバイナリを生成したり、EdisonやRaspberry Pi用のバイナリを生成できたりするのです。ただし、以下に示す、ちょっとした事前準備が必要です。 環境変数 GOOS, GOARCH を設定し %GOR
パッケージで管理すると楽なのですが ソースからインストールしたいこともあります。 でも、ソースからインストールした場合 アンインストールが大変です。。 そこで登場 「paco」 ソースからインストールしたものを パッケージ感覚で管理できるツールです。 気になってたので試してみました! 実行環境 CentOS 6.0 paco 2.0.9 pacoインストール ※実験環境用の簡易構築だったためrootで作業しています。 ソースをダウンロード、解凍してconfigureを実行。 wget http://sourceforge.net/projects/paco/files/paco/2.0.9/paco-2.0.9.tar.gz/download tar zxvf paco-2.0.9.tar.gz cd paco-2.0.9 ./configure でも、下記エラー発生... checkin
最近、Linuxではaptやyumなど、パッケージ管理ツールで多くのアプリケーションやライブラリが管理されるようになり、普通に利用している限りはソースからコンパイルして"make install"することがほとんどありません。 とはいっても、マイナーなソフトウェアをインストールしたりとか、まだパッケージ管理されていない最新バージョンのものを使いたい場合などは、ソースからコンパイルして"make install"をしたくなる場合も有るかと思います。 しかし、"make install"した場合の最大の欠点は、インストールしたソフトウェアの管理ができないことにあります。そのため、何が入っているのか分からなくなっているとか、アンインストールが出来ない、などのケースが起こりうるわけです。 特にアンインストールする可能性があるソフト(ほとんどのソフトがそうですが・・・)をインストールする場合は、わざ
新年あけましておめでとうございます。昨年一年は自分の(体重の)成長を実感できて大変残念ですね。この野郎。今年一年は減量の方ももうちょっと頑張ろうな。俺。 というわけでタイトルの話です。既にSphinxドキュメントで「.rst」ファイルが更新されたら、自動的にビルドを走らせる方法は偉大なる先人達の手によってとっくに道が開拓されているのですが、あえてまた開拓したいと思います。というか他の方法を僕がちゃんと理解できなかったので、僕の知ってる一番簡単な方法でやってみました。 先人達の足跡 特にやり方が決まってるいる話ではないので、omakeが好きな人、Makefileだけでやりたい人とかは下記記事が参考になると思います。 OMakeでSphinxドキュメントをビルドする - 偏った言語信者の垂れ流し omake を使わずに、Sphinx ドキュメントの継続的ビルド: Addicted To Ind
OMakeすごい。OMakeはマジですごい。 OMakeはGNU makeの代替品みたいなものなんだけど、正直なところこのツールの強力さはGNU makeと比べると失礼なくらいすごい。これのおかげで、「コード修正→ビルド→デバッグ→コード修正→・・・」のループの、ビルドにあたる作業がほぼ消え去った。 ファイルの依存関係の解析がとにかくすごい。よくあるユースケースなんかの場合、最小限の手間でほぼ完璧に依存関係を網羅して、よしなにビルドしてくれる。 とりあえず、はやみずが実際に使ってみたケースを例にとってそのすごさの一端を紹介しようと思う。 case study 論より証拠ということで、自分が OMake を試しにつかってみたケースを紹介する。C言語でスタティックライブラリを作っていて、それに加えて簡単なテストプログラムを書いている。 /include/ 以下にヘッダファイルが全部ある /sr
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く