Free Pascal dan Lazarus IDE mendapat dukungan dynamic package penuh untuk pertama kalinya, diumumkan di situs resmi Lazarus. Paket kini bisa dibuat sebagai shared library untuk Linux, Windows, dan macOS, dipasang tanpa membangun ulang seluruh IDE, dan diganti saat program berjalan. Ada tiga batasan yang menyertainya: nama unit tidak boleh sama dengan nama paket, nama unit harus unik antar paket, dan paket yang di-strip kehilangan metadata sehingga tidak lagi berfungsi sebagai dynamic package.
TL;DR
- Dynamic package adalah shared library berisi metadata yang dihasilkan compiler dan bisa dibaca ulang lewat RTL.
- Komponen dan ekstensi Lazarus bisa dipasang dalam hitungan detik tanpa rebuild IDE penuh.
- Program sendiri bisa membagi diri menjadi beberapa paket yang diganti saat runtime, alias sistem plugin.
- Paket lebih besar dari shared library biasa karena membawa peta isi, dan strip menghapus peta itu.
Apa itu dynamic package di Free Pascal?
Dynamic package adalah paket yang diimplementasikan sebagai file shared library standar, ditambah metadata yang dihasilkan compiler dan bisa diperiksa lewat unit RTL baru. Isinya bisa komponen, kontrol, atau ekstensi Lazarus, dan bisa juga dipakai di program sendiri untuk membangun plugin yang mengekspos kelas dan tipe Pascal native melalui library paket. Mekanisme ini dijelaskan di halaman Dynamic Packages di getlazarus.org.
Yang membuatnya berfungsi adalah runtime yang diperluas. Runtime kini punya mekanisme untuk menjaga variabel thread dan mengelola tipe dinamis seperti string dan dynamic array ketika data menyeberang antara program dan paket, atau antara beberapa paket sekaligus. Tanpa penanganan itu, menyerahkan string antar batas library adalah sumber crash yang sulit dilacak, karena manajemen memori tiap modul bisa berbeda.
Semua installer yang disediakan situs tersebut sudah membawa dukungan dynamic package, jadi tidak ada langkah tambahan untuk mendapatkan fitur ini selain memasang versi terbaru. Ini penting dicatat karena banyak tutorial Free Pascal yang beredar masih mengasumsikan paket harus ditautkan secara statis ke executable.
Kenapa ini mengubah cara memasang komponen Lazarus?
Sebelumnya, memasang komponen atau ekstensi di Lazarus umumnya berarti IDE harus dibangun ulang, dan proses itu memakan waktu. Dengan dynamic package, komponen bisa dibuat dan dipasang dalam hitungan detik tanpa rebuild penuh. Efek sampingnya lebih besar dari sekadar menghemat waktu: siklus coba dan salah saat mengembangkan komponen menjadi jauh lebih pendek, karena kamu bisa memasang, mencoba, dan melepas tanpa menunggu kompilasi IDE.
Untuk pengembangan program, perubahan yang ditawarkan berbeda sifat. Program tetap bisa dibundel menjadi satu executable tunggal seperti sebelumnya. Alternatifnya, program dipecah menjadi beberapa dynamic package yang bisa diganti saat program berjalan, dan inilah yang membuka pola plugin. Aplikasi desktop yang ingin menambah fitur dari pihak ketiga tanpa merilis ulang seluruh aplikasi bisa memakai pola ini.
Konsekuensinya, desain aplikasi perlu memikirkan batas modul lebih awal. Kalau semua kode ada di satu executable, tidak ada batas yang perlu dijaga. Kalau sebagian kode pindah ke paket, kamu perlu memutuskan apa yang diekspos, apa yang tetap internal, dan bagaimana versi paket divalidasi saat dimuat.
Apa saja batasan yang harus diketahui?
Ada tiga batasan yang disebut langsung di pengumuman resmi, dan ketiganya memengaruhi cara kamu menamai serta mengemas kode. Batasan ini bukan bug yang akan hilang, melainkan konsekuensi dari cara paket dimuat dan diidentifikasi saat runtime.
| Batasan | Penjelasan | Dampak praktis |
|---|---|---|
| Nama unit tidak boleh sama dengan nama paket | Sistem paket otomatis menambahkan kata Package pada nama paket | Paket ElectroTools.lpk menghasilkan ElectroToolsPackage.pas, bukan ElectroTools.pas |
| Nama unit harus unik antar paket | Dua paket tidak boleh berisi unit dengan nama yang sama | Konflik nama memaksa kamu memilih satu paket atau mengganti nama unit |
| Ukuran lebih besar dan tidak boleh di-strip | Paket membawa peta seluruh isinya | Strip menghapus metadata sehingga paket tidak lagi berfungsi sebagai dynamic package |
Batasan kedua yang paling sering menimbulkan kejutan. Kalau kamu memakai unit bernama Widgets dan orang lain juga menulis unit bernama Widgets, keduanya tidak bisa dipasang bersamaan. Solusinya hanya dua: pilih salah satu, atau ganti nama unit yang satu. Untuk proyek yang memakai banyak paket pihak ketiga, ini alasan kuat untuk memberi prefiks pada nama unit, misalnya nama proyek di depan nama unit.
Batasan ketiga berdampak pada proses build. Pipeline yang biasa menjalankan strip pada semua artefak shared library harus dikecualikan untuk dynamic package. Kalau tidak, paket akan tampak berhasil dibangun tapi gagal dimuat atau kehilangan kemampuan inspeksi, dan gejalanya tidak selalu jelas.
Bagaimana metadata paket dibaca dari kode?
RTL menyediakan tipe record untuk membaca isi paket, dan unit baru bernama DynPkgTypes.pas disediakan untuk membantu pekerjaan itu. Record TPackageType menyimpan unit asal tipe, nama tipe, jenis tipe, RTTI, dan kelasnya. Dengan struktur ini, program bisa mengenumerasi tipe yang diekspos sebuah paket tanpa harus tahu isinya saat kompilasi.
type
TPackageType = record
UnitName: string;
Name: string;
Kind: TTypeKind;
Info: PTypeInfo;
ClassType: TClass;
end;Arti tiap field cukup langsung. UnitName menyimpan unit yang mendeklarasikan tipe, Name menyimpan nama tipe, Kind menyimpan jenis tipe, Info menyimpan RTTI tipe tersebut, dan ClassType diisi kelas kalau Kind bernilai tkClass atau nil kalau bukan. RTTI yang sama seperti biasa bisa diambil dari sebuah paket untuk bekerja dengan isinya, jadi pola inspeksi yang sudah kamu pakai di kode Pascal tetap berlaku.
Fungsi di RTL disebut cukup lengkap untuk kebutuhan umum: memuat paket, mengenumerasi isinya, mencari tipe tertentu, dan melepas paket saat runtime. Kemampuan melepas paket inilah yang membuat hot swap mungkin. Tapi hot swap menuntut disiplin: pastikan tidak ada referensi aktif ke objek dari paket yang akan dilepas, karena melepas library yang masih dipakai akan menghasilkan crash, bukan pesan error yang rapi.
Kapan sebaiknya memakai dynamic package dan kapan tetap satu executable?
Pakai dynamic package kalau kamu butuh plugin, pembaruan komponen tanpa rebuild, atau pembagian fitur yang bisa diganti saat runtime. Tetap pakai satu executable kalau aplikasimu kecil, distribusinya sederhana, dan tidak ada kebutuhan mengganti kode setelah dipasang. Untuk aplikasi desktop yang dibagikan ke pengguna awam, satu executable biasanya lebih mudah didukung.
| Kebutuhan | Satu executable | Dynamic package |
|---|---|---|
| Distribusi ke pengguna | Satu file, paling sederhana | Beberapa file, perlu manajemen versi |
| Menambah fitur tanpa rilis ulang | Tidak bisa | Bisa, paket baru dimuat saat runtime |
| Memasang komponen di IDE | Perlu rebuild IDE | Terpasang dalam hitungan detik |
| Ukuran artefak | Lebih ringkas | Lebih besar karena membawa metadata |
| Debugging | Satu proses, jejak lebih sederhana | Perlu memeriksa batas antar modul |
| Ketergantungan antar unit | Bebas dalam satu program | Nama unit harus unik antar paket |
Untuk aplikasi internal yang dipakai tim sendiri, dynamic package sering menang karena pembaruan bisa didistribusikan sebagai paket terpisah tanpa menyentuh executable utama. Untuk aplikasi yang dijual ke publik, hitung dulu biaya dukungannya: setiap file tambahan adalah sumber masalah versi yang tidak cocok.
Apa yang perlu disiapkan sebelum mencoba?
Siapkan tiga hal: versi Free Pascal dan Lazarus yang mendukung dynamic package, daftar unit yang akan dipindah ke paket, dan rencana penamaan yang menghindari konflik. Versi compiler dan IDE bisa diperiksa di situs resmi Free Pascal serta situs Lazarus IDE, sementara catatan teknis komunitas tersedia di wiki Free Pascal.
Situs resmi Free Pascal mencantumkan versi 3.2.2 sebagai versi stabil terbaru, dengan jalur pengembangan memakai nomor 3.3.x. Installer Lazarus yang membawa dynamic package bisa dibangun dari basis compiler yang berbeda dari rilis stabil itu, jadi periksa nomor versi compiler di menu About sebelum mengandalkan fitur ini di mesin kerja.
Rencana penamaan sebaiknya dibuat sebelum paket pertama, bukan setelah konflik muncul. Aturan sederhana yang berfungsi: beri prefiks nama proyek pada setiap unit yang akan diekspos, dan jangan pernah memberi nama unit sama dengan nama paket. Kalau kamu mengikuti dua aturan itu, dua dari tiga batasan di atas tidak akan pernah menggigit.
Untuk pipeline build, tambahkan pengecualian strip pada file paket dan verifikasi hasilnya dengan memuat paket di program uji kecil. Uji itu sebaiknya memeriksa tiga hal: paket berhasil dimuat, tipe yang diharapkan muncul saat enumerasi, dan paket bisa dilepas tanpa crash. Tiga pemeriksaan itu cukup untuk menangkap kesalahan konfigurasi paling umum sebelum paket dipakai di aplikasi nyata.
Bagaimana dampaknya pada proyek yang sudah berjalan?
Untuk proyek yang sudah berjalan, dampaknya bisa nol kalau kamu tidak menyentuh paket sama sekali. Menautkan unit secara statis tetap bekerja seperti sebelumnya, dan executable tunggal tetap bisa dibangun. Perubahan baru terasa ketika kamu mulai memindahkan unit ke paket atau memasang komponen pihak ketiga yang dikemas sebagai dynamic package.
Cara bertahap yang paling aman: pilih satu modul kecil yang tidak kritikal, kemas sebagai paket, lalu muat dari program uji. Setelah pola pemuatan dan pelepasan terbukti stabil, baru pindahkan modul berikutnya. Memindahkan seluruh modul sekaligus di awal membuat sumber masalah sulit dilacak ketika ada yang gagal dimuat.
Satu hal yang perlu diingat soal kompatibilitas: kode Pascal yang memakai RTTI untuk inspeksi tipe tidak berubah, karena mekanismenya sama. Yang baru adalah sumber RTTI-nya bisa berasal dari paket, bukan hanya dari unit yang ditautkan statis. Kalau kode lamamu sudah memakai RTTI, penyesuaian yang dibutuhkan biasanya hanya pada cara paket dimuat, bukan pada cara tipe diperiksa.
FAQ
Apakah dynamic package menggantikan cara lama menautkan unit?
Tidak sepenuhnya. Menautkan unit secara statis tetap didukung, dan program masih bisa dibundel menjadi satu executable. Dynamic package adalah opsi tambahan untuk kasus yang butuh pemisahan modul, plugin, atau pemasangan komponen tanpa rebuild IDE.
Kenapa paket saya tidak berfungsi setelah di-strip?
Karena strip menghapus metadata yang dibutuhkan paket untuk berfungsi sebagai dynamic package. Paket membawa peta seluruh isinya, dan peta itulah yang dibaca runtime saat memuat serta mengenumerasi tipe. Kecualikan file paket dari langkah strip di pipeline build.
Bisakah dua paket berisi unit dengan nama yang sama?
Tidak bisa. Nama unit harus unik antar paket, jadi kamu harus memilih salah satu paket atau mengganti nama unit yang konflik. Cara paling aman adalah memberi prefiks nama proyek pada setiap unit yang akan diekspos ke paket.
Apakah fitur ini tersedia di semua platform?
Pengumuman resmi menyebut implementasinya sebagai file shared library standar untuk Linux, Windows, dan macOS. Semua installer yang disediakan situs tersebut sudah membawa dukungan ini, jadi tidak ada paket tambahan yang perlu dipasang terpisah.
💬 Komentar (0)
Belum ada komentar. Jadilah yang pertama! 💬