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
Android Studio 2.0のInstant Runの仕組みを解読する - Qiita
これは、DroidKaigi 2016のセッション「Instant Runを実現する仕組み」と連動するエントリです。セッションは30分という短い時間で行われるので、細かい説明はこちらでまとめていきます。 Part I: Instant Runを理解するためのAndroidビルド概説 はじめに 2015年11月に、Android Studio 2.0 previewと同時に公開されたInstant Runは、開発中のアプリケーションのAndroidデバイスあるいはエミュレーター（以下"target"）へのデプロイメントを高速化して、また実行中のアプリケーションを再起動することなくコードを置き換えることを可能にして、デバッグ開始までの待ち時間を劇的に減らすことが可能になりました。開発者がIDE上でデバッグを指示してから、実際のデバッグ開始まで、場合によっては1秒程度で出来てしまう、というもので
次世代ビルドツールBazelを使ってAndroidアプリをビルドする - クックパッド開発者ブログ
会員事業部所属エンジニアの山下(@tomorrowkey)です。 去年はモバイルファースト室でバリバリとAndroidアプリを書いていたのですが、今年に入ってサーバーサイドもやってみたいと思い、最近はRubyを書いている日々です。 Rubyはあまりやったことがなかったのですが、REPLがあってとても助かります。Java 9でREPLが使えるようになるらしいですが、Androidは縁遠い話ですね。 さて、今回は来年ビルドツールとして脚光を浴びそうなBazelをご紹介したいと思います。 Bazelとは何か Bazel http://bazel.io/ BazelはGoogleが社内で使用していたビルドツールをオープンソース版として開発をしているものです。2015年3月にAlpha版が公開されました。 Alpha版ではクライアントアプリケーションやiOSアプリのビルドなどがサポートされていて、最
ビッグデータツールチェインのセキュリティはビッグリスク、あるいは、誰もHadoopをスクラッチからビルドする方法を知らない件について
ビッグデータツールチェインのセキュリティはビッグリスク、あるいは、誰もHadoopをスクラッチからビルドする方法を知らない件について The sad state of sysadmin in the age of containers コンテナー時代のシステム管理者の惨状 システム管理は惨劇に見舞われている。現状は悲惨だ。 筆者は昔気質のシステム管理者に不満はない。システムの稼働を維持し、アップデートし、アップグレードする方法を知っている者達だ。 この憤りは、コンテナーと構築済みVMと、それらがもたらす、「信頼」や「アップグレード」の欠如による悲惨な惨劇に対するものだ。 例えば、Hadoopを見てみろ。誰もHadoopをスクラッチからビルドする方法を知っているようには見えないぞ。依存性とバージョンとビルドツールが悲惨なほどに絡まりあっている。 この手のイケてるツールの中で、古典的なmake
システム開発を前進させるためのGradle導入法
デブサミ2015 Growth! 【20-B-3】「システム開発を前進させるためのGradle導入法」の講演資料です。
Martin Fowler's Bliki in Japanese - ビルド言語
http://martinfowler.com/bliki/BuildLanguage.html 追記: Jon Tirsenが、Rubyを使って複雑なantビルドプロセスを動かすという面白いストーリーを書いていました。 Bruce Eckel が最近、antとmakeに関する投稿をしたのだが、それに影響を受けて、私のビルド言語に関する考えをここでシェアしておきたいと思う。 antとmakeはどちらもビルド方法を指定するものであり、ビルド方法を記述するための言語である。どちらも非常に広く使われており、成功もしている。 しかし、どちらも限界に達しているようだ。大規模システムでは、ant/makeファイルを他のプログラムから生成している人をよく見かける。 上記の理由で、私はBruceの意見に賛成なのだと思う。 簡単なビルドならば、一連のタスクと依存とで簡単に表現することが出来る。こういうビルド
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Bazel
