Saya Suka Makefile

• Meski tool build baru terus bermunculan, Makefile tetap berguna sebagai tool dasar yang ringan untuk mengelompokkan tugas berulang dalam proyek
• Berkat perintah konvensional seperti make, make build, make install, dan make dev, kita bisa cepat mencoba membangun, memasang, atau menjalankan server pengembangan pada proyek yang baru pertama kali dilihat
• Walau stack berbeda-beda seperti Jekyll, Hugo, 11ty, framework web Python, Docker, atau gulp, Makefile berperan sebagai antarmuka eksekusi bersama
• Pada proyek pribadi, beberapa target sederhana seperti dev, build, dan deploy sering kali sudah cukup dibandingkan memakai conditional atau flag
• GNU Make tersebar luas, dan kalaupun tidak tersedia, perintah shell di dalam Makefile bisa dijalankan langsung, sehingga bebannya kecil bahkan di lingkungan terbatas

---

Menggabungkan perintah yang berbeda di tiap proyek ke satu titik masuk

• Makefile digunakan untuk membungkus proyek yang cara build, menjalankan, dan deploy-nya berbeda-beda ke dalam kumpulan perintah yang familier
• Jika proyek yang baru pertama kali dilihat memiliki Makefile, biasanya perintah berikut bisa dicoba terlebih dahulu
  • make
  • make build
  • make install
• Saat membuka kembali proyek pribadi lama, proyek bisa dikonfigurasi agar cukup menjalankan make dev untuk menangani tahap build yang diperlukan sekaligus menjalankan server pengembangan
• Meski stack teknologinya berbeda seperti Jekyll, Hugo, 11ty, atau berbagai framework web Python, titik masuk yang sama tetap bisa dipertahankan
• Bahkan saat menggunakan Docker atau gulp, Makefile tidak menggantikan tool tersebut, melainkan bekerja sebagai lapisan orkestrasi
  • Contoh: make build membangun image Docker yang diperlukan sambil meneruskan argumen tambahan khusus proyek

Cara penggunaan sederhana pada proyek pribadi

• Penggunaan Makefile berfokus pada kumpulan perintah shell, bukan fitur yang kompleks
  • Tidak memakai fitur seperti conditional atau flag
  • Unit kerja make secara teknis adalah target, tetapi dalam praktiknya diperlakukan seperti task
  • Bisa juga dibuat sebagai fungsi skrip bash, tetapi Makefile dianggap lebih mudah dan cepat
• Tugas yang sering dipakai pada proyek pribadi biasanya hanya 2–3 buah
  • dev: memulai server pengembangan
  • build: membangun proyek jika diperlukan
  • deploy: men-deploy atau memublikasikan proyek
  • watch: digunakan sebagai tugas tambahan untuk menjalankan ulang build secara otomatis saat file sumber berubah
• Makefile blog saat ini hanya memiliki satu target, yaitu dev
  • Di bawah dev:, menjalankan npm run dev
• Pada proyek pribadi yang lebih kompleks, tugas berikut digabungkan dengan Makefile
  • dev: menjalankan server pengembangan dengan bundle exec jekyll serve
  • build: membangun aset dengan npm run gulp build
  • watch: memantau folder tertentu dengan npm run gulp watch
  • deploy: setelah build Jekyll di lingkungan produksi, menjalankan make encrypt dan netlify deploy --prod
  • encrypt: mengenkripsi file HTML di folder _site dengan npx staticrypt

Batasan dan kelebihan yang perlu diketahui

• Dalam contoh, phony targets dihilangkan, tetapi jika ada file bernama dev, build, watch, deploy, atau encrypt, Makefile mungkin tidak berjalan seperti yang diharapkan
  • Pembaca Hacker News menyarankan menambahkan phony target dalam kasus seperti ini
• GNU Make adalah perangkat lunak untuk menjalankan makefile, kemungkinan besar sudah terpasang di Linux, dan juga begitu umum di MacBook sampai-sampai pemasangan terpisah mungkin tidak terasa pernah dilakukan
• Karena Make tidak membutuhkan banyak dependensi tambahan, ia bisa berguna di lingkungan terbatas yang sulit atau tidak memungkinkan untuk memasang paket karena alasan keamanan
• Kalaupun Make tidak tersedia, perintah di dalam Makefile bisa disalin langsung ke shell dan dijalankan
  • Sebaliknya, jika gulp tidak ada di server, ada perbedaan bahwa kode JavaScript sulit ditempel begitu saja ke terminal untuk dijalankan
• Meski menemukan tool build baru yang lebih baik dan lebih cepat, Make tetap bisa terus dimanfaatkan sebagai lapisan perintah bersama untuk mengelola berbagai tool dan konfigurasi

[kayws426]

Untuk makefile yang tidak mendefinisikan dependensi, menggantinya dengan justfile memberikan kegunaan yang lebih baik.

[GN⁺]

Opini Hacker News

• Tidak perlu berkecil hati dengan komentar di thread ini yang mengatakan “Anda menggunakan make dengan cara yang salah.” Salah satu alasan Make adalah alat yang bagus adalah karena ia bisa dimulai dengan lebih sederhana daripada kelihatannya
  Tidak memakai .PHONY memang bisa menimbulkan masalah, tetapi untuk proyek kecil, jebakan itu mungkin baru akan terinjak setahun kemudian, dan saat itu pun kemungkinan besar selesai setelah menggaruk-garuk kepala sekitar satu jam. Dalam 99% kasus, Anda bisa langsung mulai tanpa perlu memikirkan “cara yang benar”, dan Make hanya menuntut kompleksitas secukupnya agar tidak runtuh

  • Salah satu hal terburuk dari Make adalah kelihatannya sederhana
    Make menerima berkas input dan dependensi, lalu membuat tepat satu berkas output. Aturan yang tidak membuat output seperti install, all, clean, atau semua target dalam tulisan ini, harus bergantung pada target ajaib khusus seperti .PHONY; .PHONY belum ada di POSIX 2017 (IEEE Std 1003.1-2017, https://pubs.opengroup.org/onlinepubs/9699919799/utilities/m...) dan baru masuk ke standar saat ini (IEEE Std 1003.1-2024, https://pubs.opengroup.org/onlinepubs/9799919799/utilities/m...). Jika ingin membuat banyak berkas seperti berkas objek, modul, atau header yang sudah dikompilasi sebelumnya, Anda harus merangkai sendiri trik yang rapuh. Tidak semua Make adalah GNU Make; keluarga nix seperti BSD dan Solaris/Illumos juga masih ada
    Ini bukan berarti Make tidak berguna. Ia berguna untuk proyek yang cukup kompleks, tetapi belum sampai membutuhkan sistem build yang “lebih baik”. Masalahnya, proyek seperti itu akan makin kompleks seiring bertambahnya kode, dan akhirnya memiliki skrip/program yang menghasilkan Makefile atau sebagian darinya, sehingga terbentuk sistem meta-build sementara
    Masalah yang lebih besar bukan memakainya, melainkan mengusulkannya sebagai solusi untuk “semua orang”. Dan begitu ada direktori atau berkas seperti build atau dev di root proyek, Makefile itu akan berhenti bekerja
  • Contoh Makefile yang sedikit lebih kompleks yang saya pakai saat memulai proyek TypeScript baru ada di sini: https://github.com/borisovg/node-ts-template/blob/main/Makef...
    Sekarang saya memang beralih ke pnpm, tetapi tetap saja saya tidak menganggapnya terlalu kompleks. Memang perlu tahu sintaksnya sampai batas tertentu, tetapi itu masih lebih mudah daripada membuat alat-alat lain bekerja dengan benar sejak awal
  • Selama lebih dari 20 tahun, saya menggunakan make dengan baik di banyak proyek dan berbagai bahasa, dan belum pernah mengalami masalah dengan pekerjaan .PHONY yang begitu diributkan orang
    Sederhana, mudah dibaca, bisa diubah, bisa dikomposisikan, dan sudah terpasang di mana-mana. Ia melakukan apa yang tertulis di permukaan, dan hampir tidak lebih dari itu
    Sebagai catatan, ketika harus berurusan dengan sistem build musiman atau sistem build mimpi buruk di proyek lain, saya juga membungkusnya dengan make
  • Sepenuhnya setuju. Lebih baik memakai alat yang sesuai untuk pekerjaan, dan meski bukan ahli, itu jauh lebih baik daripada memilih alat yang salah demi menghindari kritik perfeksionis
    Semua orang harus mulai dari suatu tempat, dan begitu sudah berjalan, perbaikan bertahap bisa ditambahkan dengan mudah
  • Setiap recipe makefile harus membuat tepat satu output, yaitu $@. Keseluruhan Makefile bisa membuat jumlah output berapa pun karena aturan bisa bergantung pada aturan lain
    Dari sini muncul aturan praktis yang rapi untuk target phony. Jika recipe tidak menyentuh $@, maka $@ harus ditandai sebagai phony. Mengelola target phony sebagai daftar membuatnya jauh lebih mudah
    phonies :=
phonies += something
something:
./do-something
phonies += something-else
something-else: something
./do-something-else
# touches $@ and thus does not need to be phony
create-file:
./generate-some-output > $@
.PHONY: $(phonies)

• Makefile adalah teknologi yang buruk. Namun, karena sedikit tidak seburuk kebanyakan sistem build lain yang kita buat, ia menjadi berguna dalam arti masokistis
  Sistem build biasanya terlalu mendasar sehingga menjadi kacau saat membangun sesuatu yang lebih dari mainan, atau terlalu rumit sehingga pengetahuan awal, birokrasi, sinkronisasi, dan boilerplate-nya berlebihan, atau tidak memiliki pustaka standar sehingga pola build yang sama tersebar menjadi 10 ribu implementasi yang tidak kompatibel, atau terlalu membatasi sehingga harus bermigrasi saat kebutuhan bertambah, atau terlalu banyak keajaiban, atau sintaksnya sulit dipahami dan tidak konsisten

  • Menurut saya Makefile adalah teknologi yang hebat; hanya saja banyak orang tidak mempelajarinya dengan benar atau tidak menggunakannya sesuai cara yang dimaksudkan
    Lebih dari separuh perangkat lunak yang saya pakai hanya menggunakan Makefile biasa dan sesekali skrip configure. Tanpa autotools, cukup menjalankan ./configure secara opsional lalu make, make install, dan semuanya langsung berjalan. Ini sama sekali bukan setup mainan, melainkan tersusun dari program-program kecil yang melakukan satu hal dengan baik
    Make dan cara kerjanya, setidaknya bagi saya, mudah dipahami. Menurut saya pengalaman buruk yang dialami orang sering kali lebih disebabkan konfigurasi build yang buruk pada proyek kompleks atau kurangnya pengetahuan yang diperlukan, bukan Make itu sendiri
    Tidak adanya pustaka standar memang dimaksudkan sebagai independensi dari alat, sehingga dapat diterapkan secara umum pada berbagai alat, bahasa, dan penggunaan. Saya melihatnya sebagai fitur, bukan cacat. Lapisan sederhananya adalah pelacakan dependensi, dan target serta dependensinya juga jelas, jadi sulit disebut magis. Sintaksnya memang jelas bisa dibuat lebih baik
  • Sistem build terburuk adalah yang dibuat berpusat pada bahasa pemrograman tertentu. Jika bahasanya N>>1, maka sistem build-nya juga menjadi N>>1, dan beban kognitifnya terlalu besar sehingga tidak bisa diskalakan
    Satu-satunya sistem build umum yang mencakup banyak bahasa adalah make atau sistem yang menargetkan make seperti CMake. Alasan ini kurang bagus adalah karena make memang kurang bagus. make sangat sulit digunakan dengan benar, punya masalah seperti recursive make dan non-recursive make, memiliki banyak varian yang tidak kompatibel seperti Unix/POSIX make, BSD make, GNU make, dan Windows nmake, serta cukup jelek
    Meski begitu, make yang digunakan dengan benar cukup bagus. Sungguh beruntung ada make sebagai penyebut bersama terkecil
  • Setuju. Banyak alternatifnya juga berfokus pada bahasa tertentu, bukan alat serbaguna untuk “menjalankan sesuatu” seperti Make
    Cukup konyol bahwa Make bahkan tidak bisa menangani subdirektori dengan rapi. Saya penasaran apakah ada yang lebih baik daripada Make. Ada Ninja, tetapi itu tidak dirancang untuk ditulis langsung oleh manusia
  • Bisakah kita bilang bahwa kekacauan itu “secara sangat hipotetis” sama sekali bukan karena kompiler atau bahasa tanpa modul
    Menurutmu seberapa besar? Bukankah kira-kira 20%, 40%, atau 70% benar?
  • Kalau “satu atau lebih”, ruangnya banyak. Perkiraan saya begini: Makefile tidak terlalu mendasar. Ia bisa menjadi terlalu rumit, tetapi tergantung bagaimana dibuat. Untuk pustaka standar, sebenarnya ada fungsi bawaan. Saya tidak pernah merasa terlalu dibatasi, jadi menurut saya tidak. Karena target dan dependensinya jelas, ia juga tidak terlalu banyak keajaiban. Namun sintaksnya memang jelas bisa lebih baik; bahkan file JSON biasa saja rasanya akan lebih baik

• Saya sangat menyukai Make. Selama 20 tahun terakhir, untuk setiap pekerjaan atau proyek yang saya sentuh, saya selalu menulis setidaknya satu
  Tidak ada yang pintar di dalamnya, hanya kumpulan potongan dengan beberapa variabel. Misalnya make run, make test, make lint
make recent menjalankan lint lalu mengeksekusi skrip yang paling baru dimodifikasi. Ini bisa dilakukan dengan Bash atau shell lain, tetapi kalau begitu kita tersedot ke dunia developer dan hanya menambah kompleksitas tanpa nilai tambah. Make hanyalah bahasa khusus domain untuk “file seperti ini dibuat dari file seperti ini, lalu jalankan satu atau dua perintah ini saat itu”. Karena itulah ia luar biasa kuat

  • Saya suka ungkapan “file seperti ini dibuat dari file seperti ini, lalu jalankan satu atau dua perintah ini saat itu”
    Puluhan tahun lalu saya membuat framework pengujian dengan Java, dan memungkinkan pengujian serta kelas dependensi ditentukan dengan sintaks mirip make. Ada kumpulan kelas pengujian yang mendefinisikan “paket pengujian acuan”, lalu lapisan kelas pengujian lain yang bergantung padanya hanya dijalankan jika bagian depan berhasil
    Saya tidak tahu mengapa sekarang semuanya dibuat begitu rumit. Saya selalu menyarankan untuk berpegang pada alat Unix standar dan caranya, yaitu cara yang sudah teruji waktu. Kecuali jika benar-benar tidak mungkin melakukannya begitu. Waktu itu terbatas, jadi saya ingin menggunakannya untuk hal-hal inti dalam pemecahan masalah seperti desain sistem/program, pemodelan, struktur, pola, dan sebagainya; sisanya sekunder
  • Semua Makefile yang pernah saya temui dalam praktiknya melakukan jauh lebih banyak hal daripada sekadar “itu saja”
  • Saya juga mirip. Dulu jarang menggunakannya, tetapi di tempat kerja sekarang hampir setiap repositori punya Makefile
    Mengetahui bahwa make test akan berjalan, apa pun stack, bahasa, atau repositorinya, adalah penyelamat besar
  • Masalah Make bukanlah Make itu sendiri, melainkan hal-hal yang dipanggil oleh Make kini tidak lagi bekerja sesuai model itu
    Makefile pada proyek sebelumnya punya empat perintah utama: build, test, frontend, deploy. build dan test memanggil maven, frontend memanggil npm, deploy memanggil docker dan aws
    Semua alat ini memiliki pelacakan status, caching, dan pemrosesan inkremental sendiri, tetapi tidak melaporkan apa yang telah mereka lakukan. Karena itu, kita tidak bisa menulis aturan tingkat molekuler seperti “deploy hanya jika build diperbarui”. Sebab maven/cargo/dotnet/npm/go tidak mengekspos informasi itu

• Penulis bahkan tidak memakai pelacakan dependensi berbasis mtime. Target-targetnya juga seharusnya .PHONY, tetapi tidak ditandai demikian. Ini juga bisa diganti dengan skrip shell yang membaca $1, mencocokkannya, lalu menentukan apa yang harus dilakukan

  • Atau bisa juga diganti dengan runner perintah sederhana seperti just
    https://just.systems/
  • Ada cerita horor satu baris dari proyek yang benar-benar sedang dikerjakan: .PHONY: $(MAKECMDGOALS)
./build.sh dev memang kurang jelas dibanding make dev. Alasan lain memakai Make meskipun sama sekali tidak ada tahap non-phony adalah karena nanti, jika diperlukan, tahap seperti itu bisa ditambahkan. Tentu saja saya setuju bahwa penulis seharusnya menandai {dev,build,deploy} sebagai phony
  • Secara teknis benar, tetapi inti yang saya dapat dari tulisan itu adalah mendapatkan konsistensi cara penggunaan, bukan hanya di proyek sendiri tetapi juga di proyek pihak ketiga
    Makefile miliknya mungkin bisa diperbaiki secara teknis, tetapi yang lebih penting adalah pengalaman “mulai” yang konsisten saat masuk ke sebuah proyek
  • Kita semua pernah menjadi pemula. Untuk mempelajari alat, memakai alat itu secara nyata—meski dengan cara pemula yang belum sempurna—akan membantu. Sambil belajar, kita bisa memperbaikinya secara bertahap
  • Keindahan make dan shell terletak pada kepatuhannya terhadap prinsip Unix: sederhana dan melakukan satu hal dengan baik
    Orang-orang ingin alat ini melakukan banyak hal lain seperti bahasa skrip, pelacak dependensi, dan sebagainya, lalu menarik masuk alat yang membengkak. Baru tidak selalu berarti lebih baik. Autoconf dan automake bukan make

• Secara teknis, semua target make ini mencari berkas dengan nama yang sama seperti nama target. Setiap target sebenarnya harus didefinisikan sebagai .PHONY
  Dulu saya juga selalu memakai Makefile seperti ini, tetapi beberapa tahun terakhir beralih ke just dan justfile. Perilaku seperti ini menjadi bawaan dan secara umum lebih mudah dipakai. Hal-hal seperti parameter juga lebih sederhana
  https://github.com/casey/just

  • Sistem mirip make seperti ini cukup bagus, tetapi ada satu masalah. Make sudah ada di semua Linux dan Mac, dan cukup mudah didapat di Windows. Sangat disayangkan ia tidak termasuk di Git Bash. Menurut saya, memakai penyebut bersama terendah itu sendiri adalah keunggulan besar Make
  • Kesalahan besar Make adalah mencampur target phony dan target berkas dalam namespace yang sama. Misalnya, target phony seharusnya bisa dibedakan hanya dari namanya, seperti diawali dengan :
    Tentu saja sekarang sudah terlalu terlambat
  • just benar-benar lumayan, tetapi agak merepotkan karena biasanya tidak terpasang
    Rasanya sudah waktunya ada semacam distribusi coreutils baru yang membundel alat-alat baru dan berguna seperti just dan ripgrep, lalu terpasang di mana pun kita ingin memakainya

• Menarik bahwa make memicu perdebatan sepanas ini. Mirip perdebatan lama vi vs emacs yang setengah perang agama
  Saya sepenuhnya setuju dengan tulisan asli, dan menurut saya khususnya cerdas untuk membungkus alat build yang lebih canggih sekalipun dengan Makefile tingkat atas. Keuntungannya adalah standardisasi. Tidak perlu mengingat apa pun; kalau itu proyek yang saya tulis, saya tahu cukup mengetik make dan semuanya akan berjalan
  Misalnya ketika orang yang memakai C ingin mengompilasi proyek Rust, ia tidak perlu mencari cara memakai cargo; cukup ketik make atau gmake. Saya berusaha mematuhi POSIX tanpa memakai fitur khusus GNU, tetapi juga benar bahwa hampir 100% make di dunia nyata adalah gmake
  Usulan untuk memakai make yang tak lekang oleh waktu sebagai semacam penggerak sistem build tingkat atas sepertinya masih akan bekerja 250 tahun lagi

  • Menarik bahwa judul sesederhana ini memicu debat panas. Tulisan itu sendiri adalah contoh penggunaan make yang sangat sederhana, dan membahas pemakaian gulp pada 2024, tetapi jelas tampaknya tidak ada yang membacanya
  • cargo adalah contoh yang buruk, karena secara universal orang memakai cargo build
    Make sendiri sangat bagus, tetapi pada sebagian besar kasus saya bekerja di proyek C, yang dipakai adalah kombinasi cmake/autotools dan pemasangan paket global, dan hal-hal seperti itu sering harus dicari lagi
  • Bisa jadi tidak demikian kalau sebelum itu bazel/blaze mengambil alih. Kalau ragu, lihat Chrome vs Firefox, atau Kubernetes vs docker-compose

• Saya setuju dengan sentimen di sini, tetapi saya sedang menulis ulang banyak hal menjadi Justfile
  https://github.com/casey/just
  Banyak keanehan khas Makefile bisa dihindari

  • GPT membantu menulis Makefile dan benar-benar memberi kehidupan kedua bagi Makefile, serta memperlambat kematiannya
  • Saya juga sama. Fakta bahwa berkas yang sama juga berjalan di Windows adalah bonus

• Benar, Make itu hebat. Saya memakainya untuk sangat banyak hal. Ini cara yang bagus untuk otomasi tugas
  Misalnya situs web pribadi saya memakai Makefile untuk memanggil skrip bash yang membangun ulang halaman web yang diperbarui, melakukan git push ke server, lalu git hook di server memanggil Make untuk melakukan deployment. Namun saya tidak ingin memasukkan gumpalan biner yang sering berubah seperti PDF materi kuliah ke repositori Git. Tidak masalah. Di Makefile ada target uploads yang hanya mengunggah PDF yang berubah ke server, dan target ini adalah dependensi dari target deploy yang melakukan git push, jadi saya tidak perlu memikirkannya
  Selain itu, PDF materi kuliah yang diperbarui otomatis dimasukkan ke tree sumber situs web oleh Makefile lain. Dengan Makefile itu, saya bisa membuat PDF yang saya pakai dari sumber LaTeX, atau membuat versi alternatif untuk mahasiswa dari sumber yang sama, misalnya versi tanpa jawaban soal latihan, lalu menerbitkannya otomatis ke versi situs web lokal dan mengunggahnya ke situs web yang diperbarui kapan pun saya mau
  Ini semacam rantai Makefile tanpa akhir. Saya suka Makefile

• Dalam kasus seperti ini, yang benar-benar dibutuhkan penulis bukan make, melainkan just
  https://just.systems/man/en/

  • just hanyalah dependensi tambahan. make ada di mana-mana

• Sebagai runner tugas, make tidak buruk, tetapi sekarang ada alternatif yang lebih baik seperti just, sebagaimana disebut di komentar lain
  Sebagai sistem build, make baik-baik saja sampai Anda terbentur kekurangannya. make/Makefile tidak distandardisasi, itulah sebabnya automake ada. Jadi alih-alih menulis Makefile langsung, Anda memakai template lalu membiarkannya menghasilkan makefile yang sebenarnya. Kalau Anda memiliki seluruh toolchain sendiri, itu tidak masalah, tetapi kebanyakan orang tidak demikian, jadi ini dilakukan untuk menjamin Makefile yang portabel
  make tidak bisa melakukan resolusi dependensi jenis apa pun dan berasumsi bahwa apa yang dibutuhkan sudah ada persis di sana. Karena itu muncullah skrip configure, dan karena skrip configure juga bukan standar, Anda akhirnya membuat skrip configure dengan autoconf/autoreconf sebelum menjalankan target make
  make dan alat-alat di sekitarnya seperti automake/autoconf/autoreconf memakai mtime saat menentukan apakah input sudah usang. Anda bisa terjebak dalam situasi ketika setelah menjalankan autoconf/autoreconf/automake/configure pun input tetap dianggap usang secara permanen sehingga tidak ada yang bisa dibuild. Sebagai catatan, banyak sistem build baik-baik saja memakai mtime selama pelacakan dependensinya tepat
  Secara keseluruhan, cacat desain mendasar make adalah ia selaras dengan filosofi Unix, yaitu “lakukan satu hal dengan baik”. Satu hal itu adalah “build ulang target jika inputnya sudah usang”, tetapi ini adalah alat yang sangat terbatas, sehingga sistem build modern harus menumpuk banyak pekerjaan di atasnya agar berguna lebih dari sekadar runner tugas dasar

  • make tidak bisa melakukan resolusi dependensi?
    dependency:
...
target: dependency
...
  • Mungkin ini pertanyaan bodoh, tetapi bukankah resolusi dependensi itu inti dari make? Apa tepatnya yang dimaksud di sini?
  • Konvensi lama di sana adalah make configure. Ini menyiapkan hal-hal yang dibutuhkan untuk make [build]
  • Yang benar-benar saya rasa kurang dari make hanyalah kemampuan untuk menafsirkan mtime berdasarkan kriteria selain mtime
    Karena itu kita akhirnya memakai touchfile; memang berantakan, tetapi masih bekerja lebih baik daripada banyak hal lain. Saya terutama mengatakan ini sambil melihat caching docker build