sed awk make 互換性 つらい うんざりザリガニ - Lambdaカクテル
仕事でsedのコードをパパッと書いて使ったら、コードレビューで動かんと言われてしまった。そういえば、同僚はMacで、おれはLinuxだったな。 まぁsedならよくある話なので、しょうがないと思ってawkで同じことをした。awkは比較的もうちょっと互換性がある気がしているからだ(どっこいどっこいな気もする)。 しかしまだ動かないと言う。もう、大絶叫だ。アー。おしまいだ。カスがよ〜〜〜と思いつつ(社会人なので絶叫はしない)、よく調べてみるとmakeの互換性だった。というのも、試しにbrew install makeしてGNU Makeで試してみてくれ、と言ったら、あっさり動いたからである。実はsedもawkも悪くなくて、そいつを呼び出してるmakeに互換性がなかった。ごめんな、お前たち悪くなかったよ。でもそれはそうと互換性はない。 define foobarstring ... endef #
Makefile覚書: Goアプリ開発に役立ちそうな基礎知識 | フューチャー技術ブログ
はじめにTIG真野です。育休明けです。 フューチャー社内のタスクランナーはmakeやTaskなど複数の流派があり、チームによって使い分けられています。個人的にはmakeで良いんじゃないかと思っていますが、Taskも良いですよね。 makeは細かい記法をいつも忘れる＋調べるとC言語向けの情報が出てきて脳内変換に手間を感じたため、makeを用いてWebバックエンドアプリをGoで開発するということをテーマに、役立ちそうな情報をまとめます。 なお、今記事におけるmakeは、GNU Makeを指します。バージョンは以下で動かしています。 MakefileのためのEditorConfigMakefileのインデントはハードタブである必要があります。誤りを防ぐためにもEditorConfigを設定しておくと良いでしょう。 makeは通常、Makefileという名称をデフォルトで認識しますが、同一フォルダ
Golangでバイナリを配布するとき、go-licensesとgoxzを使って利用モジュールのLICENSE、NOTICEを同梱する - 理系学生日記
Golangで作ったプロダクトを公開・配布するとき、課題となるのが利用するモジュールのライセンスです。 MITライセンスであれ、MPLライセンスであれ、利用するモジュールのLICENSEやNOTICEファイルを同梱することになるでしょう。 goxzとgo-licensesを使うと、クロスビルドした実行バイナリと利用モジュールのLICENSE等を含め頒布物を作成できるようになります。 最終イメージ 同梱されていることの確認 go-licenses ハマりポイント goxz まとめ 最終イメージ 最終イメージですが、以下のようなMakefileを用意しました。 プロダクトに設定したライセンスで利用できないモジュールがあるかどうかをlicense-checkで確認した後、cross-build.shを呼び出します。 .PHONY: license-check license-check: go-
Rust for Linuxでは独自のallocライブラリを使っている
Rustを第二言語として採用してデバイスドライバなどのモジュールをRustで書けるようにする「Rust for Linux」が近々マージされる予定だともLinus氏自身が発言しています。 そんな期待のかかるRust for Linuxですが、提案された当初は期待こそされていたものの、様々な懸念点も指摘されていました。 その1つが標準ライブラリの一部であるallocクレートの設計です。 このクレートはヒープ領域を扱うBox、Vec、StringなどRustではお馴染みの構造体を提供しています。 Rustの標準ライブラリはOSのサポートを前提とした構造体も多くあります。そのため、OSそのものを書くようなベアメタルプログラミングにおいて標準ライブラリをそのまま使うことはできません。 使えるのはcoreと呼ばれる依存関係のない全く無いライブラリがありますが、allocはOSのサポートが必要なヒープ
ZigはCMakeの代替となるか
既存のプロジェクトで使用しているコンパイラを置き換えるだけで、Zigに付属しているCコンパイラを利用できる。 クロスビルドが標準で可能 上でも述べた通り、Zigは標準でクロスコンパイルが可能である。 Zig libcのTaget一覧 ❯ zig targets | jq ".libc" [ "aarch64_be-linux-gnu", "aarch64_be-linux-musl", "aarch64_be-windows-gnu", "aarch64-linux-gnu", "aarch64-linux-musl", "aarch64-windows-gnu", "aarch64-macos-none", "aarch64-macos-none", "armeb-linux-gnueabi", "armeb-linux-gnueabihf", "armeb-linux-musleabi
味玉のレシピをMakefileで記述する - 私が歌川です
最近よく味玉を作っているのだけど、ジップロックに日付を記入し忘れたり、ボウルに水を入れてから氷を入れようとしたりしていて、手順の依存関係を意識しないとめちゃくちゃになる。 Makefileは依存関係と成果物を記述できるので、レシピをMakefileの形で書いたらおもしろいのでは、と思ったけど記述量が多い気がする。 .PHONY: お湯を湧かす 卵を茹でる 8分待つ ボウルに氷を入れる ボウルに水を入れる ボウルに卵を入れる 卵の殻を剥く ジップロックに日付を書く ジップロックにめんつゆを入れる ジップロックに卵を入れる 一晩寝かせる 味玉 お湯を湧かす: @echo お湯を湧かします 卵を茹でる: お湯を湧かす @echo 卵を茹でます 8分待つ: 卵を茹でる @echo 8分待ちます ボウルに氷を入れる: 8分待つ @echo ボウルに氷を入れます ボウルに水を入れる: ボウルに氷を入れ
Makefileの代わりにnpm scripts+zxを使う - 詩と創作・思索のひろば
そこそこの規模があるプロジェクトで実行すべきタスクを定義するとき、初手として Makefile を使いがち。 Pros make は事実上どんな環境にもあることを期待してよい シェルで実行されるコマンドをそのまま書ける タスクの依存関係が明示できる Cons make では positional arguments が使えない 少し複雑なことをしようとすると Makefile 専用の文法を覚える必要がある 現代では、ファイルベースのタスクの依存関係は make が発明されたころほどは必要ではない Docker とか Go とか Webpack がよしなにしてくれることが多い 例: docker compose のラッパー ちょっとしたコマンドのラッパーを書きたいことがある。Makefile を書きはじめたらすべてのエントリポイントを make にしたい。ということで、以下のような Make
シェルスクリプトの代替
要約：決定版はとくにない。 kzys氏のシェルスクリプトを書かないという記事は面白かった。 https://blog.8-p.info/ja/2021/09/15/bash/ シェルスクリプト、ごくたまに書くことはあるが、ほんともう細かい話とかはすべて忘れているし、覚える価値を感じない。いまさら覚える必要のない技術だなと感じる。が、その一方でなかなか代替品がないようなニッチでもある。 自分は必要に応じてPythonかRubyか、といったあたりを使うことが多いが（perlはもう書けなくなった）、なかなかこれという感じには思い至らない。なにがいいんだろうね？という。 前提条件：インタラクティブな環境（REPL）はなくてもいい。そこはもう既存のシェルでいい。自動化したシェルスクリプト的なタスク記述を目標とする。bashの置き換えという意味では「どこにでもインストールされていることを前提にしないと
JUCE+CMake+Android now works - ものがたり
JUCE6はCMakeに対応していますが、実はCMake対応の恩恵を受けられないプラットフォームが存在します。Androidです。 「は?」というのが多分一番正しいでしょう。何しろCMakeはだいぶ前からAndroid Studioでサポートされているわけで、むしろ一番恩恵を受けるべきプラットフォームです。Win/Mac/Linux/iOSのいずれもCMakeネイティブなビルド環境ではないのに、むしろCMakeがネイティブのビルド環境としてサポートされているAndroidがなぜかサポート外になっているのです。このままではいけない。 目次 Missions 分析編 一般的なAndroid C++サポートの実現方法 ProjucerのAndroidExporterで生成されるファイル build.gradle, local.properties, settings.gradle, gradle
komake: Make の -j オプションに潜む罠とその解決策
ビルドツールのダジャレの大家と言えば @shinh さんですが、それはさておき、皆さんは今でも Make を使ってビルドすることが多いと思います。かく言う私も、その一人。 最近は CPU のコア数も多いですから、当然 -j 16 とか、やりたいわけです。大きいプロジェクトになればなるほど、威力絶大ですね。 ですが、ここで問題がひとつ。大規模プロジェクトでは Makefile が別の Makefile を呼び出すような依存関係が良く見受けられます。この際、ターゲット間の依存関係で菱形が存在すると（例: ターゲット sub1 と sub2 が shared に依存）、make shared が make sub1 と make sub2 から同時に起動されることが起こりえます。CMake で生成した Makefile の場合も、ターゲット毎に make を起動しますね。 二重起動が発生すると、
pipでのuWSGIのインストールが"ModuleNotFoundError: No module named '_ctypes'"で失敗する - かつおのお刺身
pipはPythonに同梱されているパッケージマネージャであり、uWSGIはPythonで製作されたウェブアプリを実行するためのソフトウェアです。本記事ではpipでuWSGIをインストールする際、ModuleNotFoundError: No module named ‘_ctypes’でインストールが失敗する場合の対処法を紹介します。 libffiをインストールする PythonのctypesはCで書かれたライブラリをPythonから利用するためのモジュールであり、libffiに依存しています。ソースからPythonをビルドする際、libfflが見つからない場合はctypesのビルドはスキップされます。ctypesがビルドされていないPythonからctypesを利用しようとすると、以下のように当該エラーが発生します。 $ pip3 install uwsgi Collecting uw
Go で書いた CLI ツールのリリースは GoReleaser と GitHub Actions で個人的には決まり - tellme.tokyo
Go で書いた CLI ツールのリリースは GoReleaser と GitHub Actions で個人的には決まり February 4, 2020 lt;dr GoReleaser と GitHub Actions を使うと簡単にビルドしたバイナリを作ってアップロードできる。 2つの YAML を書いてリポジトリにコミットする .github/workflows/release.yml .goreleaser.yml git tag して push する バイナリがリリースされる 専用のツールをローカルにインストールする必要はない。 本題 前に、Go のコマンドラインツールを簡単にリリースする | tellme.tokyo というブログを書いた。 それよりももっと楽になったので紹介する。 基本的にこのページで紹介する方法では 2 つの YAML をリポジトリに置くだけで終わる。 ロー
至高のDockerイメージ生成を求めて -2019年版- - Qiita
この記事は@yugui氏の書いた至高のDockerイメージ生成を求めてに感謝しつつ、記事が投稿された当時には無かったさまざまな事情を組み込んで再度まとめたものである。 良いDockerイメージ 良いDockerイメージとは何だろうか。Dockerの利点は次のようなものだから、それを活かすイメージが良いものであるに違いない。 ビルドしたイメージはどこでも動く 適切にインストールされ、設定されたアプリケーションをそのままどこにでも持っていける。 コンテナ同士が干渉し合うことはないので、任意のイメージを互いに配慮することなく柔軟に配備し実行できる 必要のないサービスがコンテナ内で走っていないので、セキュリティの向上に資する イメージの転送が効率的である ベースイメージ部分は一度送ればいちいち再転送する必要がないので、ベースイメージを共有する複数のイメージを効率的に転送できる 標準のレジストリAP
江添亮のC++入門
序 本書はプログラミングの経験はあるがC++は知らない読者を対象にしたC++を学ぶための本である。本書はすでに学んだことのみを使って次の知識を説明する手法で書かれた。C++コンパイラーをC++で書く場合、C++コンパイラーのソースコードをコンパイルする最初のC++コンパイラーをどうするかというブートストラップ問題がある。本書はいわばC++における知識のブートストラップを目指した本だ。これにより読者は本を先頭から読んでいけば、まだ学んでいない概念が突如として無説明のまま使われて混乱することなく読み進むことができるだろう。 C++知識のブートストラップを意識した入門書の執筆はなかなかに難しかった。ある機能Xを教えたいが、そのためには機能Yを知っていなければならず、機能Yを理解するためには機能Zの理解が必要といった具合に、C++の機能の依存関係の解決をしなければならなかったからだ。著者自身も苦し
開発イテレーション偏重 - 兼雑記
開発イテレーションを早くすれば、かなりの問題が勝手に解決される、と信じています。なんか最近、他の要素を軽視しすぎていたり、特にイテレーション速度に影響しなさそうなことすらしている気がしていて、信仰とかのレベルかもしれない、という気がしてきたので、ちょっと書いてみようかなと。主に C++ の話です。 仕事とかしてると良い判断力が求められたりしますが、判断というのは結構難しいですよね。アプローチ A と B で悩んだ時に、手が速ければ両方できたりします。開発イテレーションを無限に速くすると、必要とされる判断力はゼロに漸近していきます。やったね。 2手で変更の正当性を高速に確認できるようにする make (かその他のビルドコマンド)てやったらビルドができて、 make check (かその他のテストスクリプト)てやったら遅くないテストが全部走る、という体勢が好きです。試すためにはあっちのディレク
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://twitter.com/yugui/status/1628932091621801984
GitHub - phracker/MacOSX-SDKs: A collection of those pesky SDK folders: MacOSX10.1.5.sdk thru MacOSX11.3.sdk
現代開発を加速させる古来の術式
Makefile with Python
GitHub - uutils/coreutils: Cross-platform Rust rewrite of the GNU coreutils
