PHP8.4が出ましたね 🎉 tl;dr 今日のお話は、 「jdkfxさんが用意してくれた環境がメッチャ便利で最高だったよ」という内容です。 https://github.com/jdkfx/phpdoc イントロ 最近coreへの貢献をしている人が身近(？)でも増えているし、日本人でコアなデベロッパーはすごすぎる・・なんてものを眺めていて。 うぉ〜〜俺もなんかしてぇ〜〜〜！！ってなるじゃないですか。 もともと「お世話になっているコミュニティやOSSには沢山恩返ししたいな」と思っていて、カンファレンスやOSS作者や団体に向かって個人スポンサーをやったりはしています。 ただ、自分の中では、受けている恩ってそれだけで返しきれるものでもなく。 最大の恩返しは「もっと盛り上げる！」だとも考えていて、それって「賑やかす」「開発や利用しやすさの改善に貢献する」が効きそうだな〜とも思っている訳です。
https://github.com/google/kati kati について、ドキュメント書こう…と思っていたのですがなかなか進まないので、とりあえず日本語で書いてみることにしました。何書くかがあまり明確じゃないテーマなので、何書くか考えるのと英語考えるのを両方同時にやるのが少し大変で。 動機 kati は GNU make のクローンです。いずれ完全なコンパチになると嬉しいですが、なかなか難しいだろうと個人的には諦めています。用途に対して実用的ならば良いかなと。 動機としては、 Android platform のビルドシステムが、なかなかシュールな GNU make 黒魔術で構成されていて、 make が実際になんかしはじめるまでが遅かったので、そこを高速化したいというものでした。 ビルドシステムが遅いという時、まずだいたいヌルビルドとフルビルドの2点を考えます。ヌルビルドてのは生
SREチームの長田です。 みなさま開発・運用上の定形オペレーションに伴うタスク実行をどのように管理していますか？ 今回は make をタスクランナーとして使う例を紹介します。 タスクランナーがほしい タスクランナーを使う主なモチベーションは以下の2つです。 タスクをリスト化したい タスクの実行インターフェイスを統一したい タスクがリスト化されていれば、それ自体が生きたドキュメントとして機能します。 また、タスクの実行インターフェイスが統一されていれば、 例えばタスクに前処理や後処理を追加したとしても、 開発・運用メンバーが実行するべき操作が変わることはありません。 操作変更の周知コストも下がりますし、変更に伴う操作ミスも減らすことができます。 タスクランナーに求めるもの タスクランナーの機能としては必要最低限のものがよいと考えています。 高機能なタスクランナーも魅力的ではあるのですが、タス
はじめにTIG真野です。育休明けです。 フューチャー社内のタスクランナーはmakeやTaskなど複数の流派があり、チームによって使い分けられています。個人的にはmakeで良いんじゃないかと思っていますが、Taskも良いですよね。 makeは細かい記法をいつも忘れる＋調べるとC言語向けの情報が出てきて脳内変換に手間を感じたため、makeを用いてWebバックエンドアプリをGoで開発するということをテーマに、役立ちそうな情報をまとめます。 なお、今記事におけるmakeは、GNU Makeを指します。バージョンは以下で動かしています。 MakefileのためのEditorConfigMakefileのインデントはハードタブである必要があります。誤りを防ぐためにもEditorConfigを設定しておくと良いでしょう。 makeは通常、Makefileという名称をデフォルトで認識しますが、同一フォルダ
GNU Make、43才。内向的で人づきあいが苦手という以外は全く普通のプログラムだったはず。外見はそっくりだけれども予想外の用途の出現。その周りで起こる不可思議な事件は切り離されていたはずの伝統的ビルドオートメーションの世界とウェブ開発の世界の境が崩れ始める予兆。引き込まれて戻れなくなる、カルティック･サイコホラー。 GitHub:https://github.com/voyagegroup/make-advent-calendar-2020 293012020年の Makefile2偽のターゲットと前提条件3変数4自動変数5-C オプションと -f オプション6デフォルトターゲット7終了ステータス8文字列の関数9ファイル名の関数10リストの関数11shell 関数12パターンルール13パターンルールと黒魔術14151617181920212223242526272829303112
最近よく味玉を作っているのだけど、ジップロックに日付を記入し忘れたり、ボウルに水を入れてから氷を入れようとしたりしていて、手順の依存関係を意識しないとめちゃくちゃになる。 Makefileは依存関係と成果物を記述できるので、レシピをMakefileの形で書いたらおもしろいのでは、と思ったけど記述量が多い気がする。 .PHONY: お湯を湧かす 卵を茹でる 8分待つ ボウルに氷を入れる ボウルに水を入れる ボウルに卵を入れる 卵の殻を剥く ジップロックに日付を書く ジップロックにめんつゆを入れる ジップロックに卵を入れる 一晩寝かせる 味玉 お湯を湧かす: @echo お湯を湧かします 卵を茹でる: お湯を湧かす @echo 卵を茹でます 8分待つ: 卵を茹でる @echo 8分待ちます ボウルに氷を入れる: 8分待つ @echo ボウルに氷を入れます ボウルに水を入れる: ボウルに氷を入れ
そこそこの規模があるプロジェクトで実行すべきタスクを定義するとき、初手として Makefile を使いがち。 Pros make は事実上どんな環境にもあることを期待してよい シェルで実行されるコマンドをそのまま書ける タスクの依存関係が明示できる Cons make では positional arguments が使えない 少し複雑なことをしようとすると Makefile 専用の文法を覚える必要がある 現代では、ファイルベースのタスクの依存関係は make が発明されたころほどは必要ではない Docker とか Go とか Webpack がよしなにしてくれることが多い 例: docker compose のラッパー ちょっとしたコマンドのラッパーを書きたいことがある。Makefile を書きはじめたらすべてのエントリポイントを make にしたい。ということで、以下のような Make
Makefile の組み込み関数の一覧です。 公式のドキュメントを読みながら、関数の引数と使い方について備忘録としてまとめました。 Makefile での関数の書き方は $(関数名 引数,...) または ${関数名 引数,...} です。 文字列操作・検索の関数 subst 文字列の置換です。使い方は $(subst 置換前,置換後,対象) FILES := hoge.c hoge.h fuga.c fuga.h all: @echo $(subst hoge,piyo,$(FILES)) # => piyo.c piyo.h fuga.c fuga.h patsubst パターンマッチによる文字列の置換です。使い方は $(patsubst 置換前,置換後,対象) FILES := hoge.c hoge.h fuga.c fuga.h all: @echo $(patsubst %.c
VOYAGE GROUP でお手伝いしているとmakeに詳しくなる。 Makefileなにもわからん。 読むのはまだしも、スラスラ書けんな。— そーだい@初代ALF (@soudai1025) 2020年12月22日 嘘、やっぱなにもわからん。 アイスブレイクはこれくらいにしておいて、本題に入る。 同じ処理を繰り返し、実行したいことは多々ある。 更にその処理を並列にしたいことも多々ある。 そんなとき、makeが便利なので使い方を紹介する。 やりたいこと 例えば次のような処理。 CSVファイルを読み込む INSERT文に変換してDBに取り込む CSVファイルは経理データだったり、アクセスログだったりで、この処理を書くことは日常的にあると思う。 この場合にCSVファイルが例えば日付別にあって、一度で取り込みたい場合にどうするだろう？ 一番シンプルなのはファイル名の一覧を取得し、その一覧をもとに
Bazelの特徴2：ビルドによってディレクトリを汚染しない Bazelでは、ソースコードやテストデータなどが格納されているディレクトリとは別のディレクトリでビルドやテストなどを行う仕組みになっている。makeコマンドでは意図的に設定や操作を行わない限りソースコードと生成物が同じディレクトリに混在する事態になることが多いが、Bazelではこういった問題が発生しない。 また、ビルドやテストはデフォルトではサンドボックス化された環境で行われるため、ビルドやテストがそれを実行しているシステムに影響を及ぼす可能性が最小限に抑えられている。 Bazelの特徴3：並列ビルド 大規模なソフトウェアではビルド対象が増えるため、ビルドにかかる時間も増える傾向がある。Bazelでは生成物どうしの依存性を自動的に把握し、可能な限り並列でビルドを実行する仕組みになっている。これにより、ビルド時間の短縮が期待できる。
Makefile での .PHONY と FORCE の違い
[以前](/2012/02/linuxmakefile-4.html)、 `.PHONY:` 指定と `: FORCE` 指定について触れたことがあるのですが、 明らかに両者を使い分けるべきケースがあることに最近気がついた。 まずは、 make の初歩ですが、 PHONY ターゲットからおさらいします。 次のような `clean` ターゲットがあったとする。 clean: $(RM) $(programs) $(objects) もし、カレントディレクトリにたまたま `clean` という名前のファイルが存在すると、 この `clean` は実行してくれません。 $ touch clean $ make clean make: `clean' is up to date. そこで、 .PHONY: clean clean: $(RM) $(programs) $(objects) としてお
私の大好きな Makefile の話が盛り上がっていたのでまとめました。 「やめてね。」って方はお声がけください。 同じ会社にいるけど、真逆の感想を持っている。Makefile読まないと副作用が分からないし、Rakefile/package.jsonだけで済むのに無駄に1つレイヤ増えていて、Makefileできたときからいる人は楽だけど、途中から入った人にとっては学習コストが高い。 https://t.co/EXtmI3xl72— 神速 (@sinsoku_listy) 2020年9月13日 golangでMakefileを使うのは分かる。 ただ、RubyやNode.jsのリポジトリなら $ git clone xxx $ cd xxx $ bundle install && rake もしくは npm install && npm test で環境構築ができることを期待する。— 神速 (
Upon receiving suggestions from readers via Email, Hacker News and Reddit, I’ve updated the article with improvements and fixes. Subsequently a word of thanks to the readers for the suggestions. We’ve been using make as a build tool for one of our projects at HackerRank which is written in Go and it has been working out fairly well. In this post, I’ll point out a few features and intricacies of GN
Your Makefiles are full of tabs and errors. An opinionated approach to writing (GNU) Makefiles that I learned from Ben may still be able to salvage them. An opinionated approach to (GNU) Make This is my second hand account of the approach to Make that I learned from Ben. If something is wrong, assume it was lost in translation. The big things I hope you take away are: The file system is a fundamen
最近は仕事でも新しくGoのプロジェクトをイチからはじめることが増えてきて、コピペ元が欲しくなるので、スナップショットとして残しておきます。とくに Go でウェブアプリケーションを書くような場合を想定していて、npm エコシステムにも乗っていきます。 大まかな方針としては、 self-contained である グローバルな環境を汚染しない コマンド一発で開発環境が再現できる ……というところを目指します。 motemen/prchecklist がこれを達成しているつもりなので、以下、これを例に見ていきます。 依存ライブラリは dep なり何かしらのツールと Go 標準の vendoring で管理すればよい一方、そのツール自体であったり、他の開発中に必要なツール（golint とか gobump とか）であったりのインストールをどうするかという話。 npm であれば devDepende
まえがき その昔、Makefileの書き方という非常にわかりやすいMakefileの入門ページがあったのですが、seiichirou氏の卒業（？）とともにページが消えてしまいました。 私も大変お世話になったページだった、というかこれからもお世話になりそうなので、そこでWebArchiveから引っ張りだしてきたものを、はてな記法で書き直したものがこの記事になります。 元々自分用に書き直したのですが、せっかくなので公開してみます。 なので、以下の著作はseiichirou氏に帰属します*1。 Makefileの書き方 はじめに ここでは、Makefileの中でもGNU makeにかぎって説明します。 makeって何？ ソースファイルを分割して大規模なプログラムを作成していると、コマンドでコンパイルするのが面倒です。また、一部のソースファイルを書き換えただけなのに全部をコンパイルし直すのは時間の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
とあるエンジニアの備忘log