kotlin native что это
Kotlin Native
Kotlin/Native is a technology for compiling Kotlin code to native binaries which can run without a virtual machine. Kotlin/Native includes an LLVM-based backend for the Kotlin compiler and a native implementation of the Kotlin standard library.
Why Kotlin/Native?
Kotlin/Native is primarily designed to allow compilation for platforms on which virtual machines are not desirable or possible, such as embedded devices or iOS. It is ideal for situations when a developer needs to produce a self-contained program that does not require an additional runtime or virtual machine.
Target platforms
Kotlin/Native supports the following platforms:
Interoperability
Kotlin/Native supports two-way interoperability with native programming languages for different operating systems. The compiler creates:
an executable for many platforms
a static library or dynamic library with C headers for C/C++ projects
an Apple framework for Swift and Objective-C projects
Kotlin/Native supports interoperability to use existing libraries directly from Kotlin/Native:
It is easy to include compiled Kotlin code in existing projects written in C, C++, Swift, Objective-C, and other languages. It is also easy to use existing native code, static or dynamic C libraries, Swift/Objective-C frameworks, graphical engines, and anything else directly from Kotlin/Native.
Kotlin/Native libraries help share Kotlin code between projects. POSIX, gzip, OpenGL, Metal, Foundation, and many other popular libraries and Apple frameworks are pre-imported and included as Kotlin/Native libraries in the compiler package.
Sharing code between platforms
Multiplatform projects allow sharing common Kotlin code between multiple platforms, including Android, iOS, JVM, JavaScript, and native. Multiplatform libraries provide required APIs for common Kotlin code and help develop shared parts of a project in Kotlin in one place and share it with some or all target platforms.
You can use Kotlin Multiplatform Mobile (KMM) to create multiplatform mobile applications with code shared between Android and iOS.
How to get started
Tutorials and documentation
New to Kotlin? Take a look at Getting started with Kotlin.
Kotlin Native: следите за файлами
Когда вы пишите command line утилиту, последнее, на что вам хочется полагаться, так это на то, что на компьютере где она будет запущена установлен JVM, Ruby или Python. Так же хотелось бы на выходе иметь один бинарный файл, который будет легко запустить. И не возиться слишком много с memory management’ом.
По вышеозначенным причинам, в последние годы всегда, когда мне нужно было писать подобные утилиты, я использовал Go.
У Go относительно простой синтаксис, неплохая стандартная библиотека, есть garbage collection, и на выходе мы получаем один бинарник. Казалось бы, что еще нужно?
Не так давно Kotlin так же стал пробовать себя на схожем поприще в форме Kotlin Native. Предложение звучало многообещающе — GC, единый бинарник, знакомый и удобный синтаксис. Но все ли так хорошо, как хотелось бы?
Задача, которую нам предстоит решить: написать на Kotlin Native простой file watcher. Как аргументы утилита должна получать путь к файлу и частоту проверки. Если файл изменился, утилита дожна создать его копию в той же папке с новым именем.
Иначе говоря, алгоритм должен выглядеть следующим образом:
Ладно, с тем чего хотим добиться вроде бы разобрались. Время писать код.
Среда
Первое, что нам потребуется — это IDE. Любителей vim попрошу не беспокоиться.
Запускаем привычный IntelliJ IDEA и обнаруживаем, что в Kotlin Native он не может от слова совсем. Нужно использовать CLion.
На этом злоключения человека, который в последний раз сталкивался с C в 2004 еще не окончены. Нужен toolchain. Если вы используете OSX, скорее всего CLion обнаружит подходящий toolchain сам. Но если вы решили использовать Windows и на C не программируете, придется повозиться с tutorial’ом по установке какого-нибудь Cygwin.
IDE установили, с toolchain’ом разобрались. Можно уже начать код писать? Почти.
Поскольку Kotlin Native еще несколько экспериментален, плагин для него в CLion не установлен по умолчанию. Так что прежде, чем мы увидим заветную надпись «New Kotlin/Native Application» придется его установить вручную.
Немного настроек
И так, наконец-то у нас есть пустой Kotlin Native проект. Что интересно, он основан на Gradle (а не на Makefile’ах), да еще на Kotlin Script версии.
Заглянем в build.gradle.kts :
Единственный плагин, который мы будем использовать называется Konan. Он то и будет производить наш бинарный файл.
В konanArtifacts мы указываем имя исполняемого файла. В данном примере получится file_watcher.kexe
Пора бы уже и код показать. Вот он, кстати:
Обычно у command line утилиты бывают так же опциональные аргументы и их значения по умолчанию. Но для примера будем предполагать, что аргумента всегда два: path и interval
Если вы вдруг не знакомы с функцией require() в Kotlin — это просто более удобный способ для валидации аргументов. Kotlin — он вообще про удобство. Можно было бы написать и так:
В целом, тут пока обычный Kotlin код, ничего интересного. А вот с этого момента станет повеселей.
Давайте будем пытаться писать обычный Kotlin-код, но каждый раз, когда нам нужно использовать что-нибудь из Java, мы говорим «упс!». Готовы?
Thread — это класс из Java. Мы не можем использовать Java классы в Kotlin Native. Только Kotlin’овские классы. Никакой Java.
Кстати, потому в main мы и не использовали java.io.File
Хорошо, а что тогда можно использовать? Функции из C!
Добро пожаловать в мир C
Теперь, когда мы знаем что нас ждет, давайте посмотрим как выглядит функция exists() из нашего File :
Дальше по списку у нас функция modified() :
Высвобождать эти структуры тоже нужно вручную. Тут на помощь приходит функция memScoped() из Kotlin Native, которая это сделает за нас.
Нам осталось рассмотреть наиболее увесистую функцию: сopyAside()
Но и высвобождать нам эту структуру приходится самим — используя
copyfile_state_free(state)
Последнее, что осталось показать — это генерация имен. Тут просто немного Kotlin:
Это довольно наивный код, который игнорирует многие кейсы, но для примера сойдет.
Теперь как все это запускать?
Один вариант — это конечно использовать CLion. Он все сделает за нас.
Но давайте вместо этого используем command line, чтобы лучше понять процесс. Да и какой-нибудь CI не будет запускать наш код из CLion.
Первым делом мы компилируем наш проект используя Gradle. Если все прошло успешно, появится следующее сообщение:
Шестнадцать секунд?! Да, в сравнение с каким-нибудь Go или даже Kotlin для JVM, результат неутешителен. И это еще крошечный проект.
Теперь вы должны увидеть бегущие по экрану точки. И если вы измените содержимое файла, об этом появится сообщение. Что-то вроде такой картины:
Время запуска замерить сложно. Зато мы можем проверить, сколько памяти занимает наш процесс, используя к примеру Activity Monitor: 852KB. Неплохо!
Немного выводов
И так, мы выяснили что при помощи Kotlin Native мы можем получить единый исполняемый файл с memory footprint’ом меньше, чем у того же Go. Победа? Не совсем.
Как это все тестировать? Те кто работал с Go или Kotlin’ом знаю, что в обоих языках есть хорошие решения для этой важной задачи. У Kotlin Native с этим пока что все плохо.
Вроде бы в 2017ом JetBrains пытались это решить. Но учитывая, что даже у официальных примеров Kotlin Native нет тестов, видимо пока не слишком успешно.
Все примеры кода вы можете найти тут
И ссылка на мою оригинальную статью, если вы предпочитаете читать на английском
Быстрые прототипы на Flutter и Kotlin/Native
Получив задачу разработать приложение для нашей предстоящей внутренней конференции в рамках OLX Group, моя команда задумалась о том, как сократить время создания приложения для iOS и Android, потому что нам и без этого было чем заняться. Первое, что мне пришло в голову, — использовать Kotlin, т.к. он может компилироваться на других платформах. Спойлер: не все пошло так, как изначально планировалось, но мы сделали всё вовремя, попутно узнав много нового!
Итак, это рассказ о том, как мы делали приложение OLX Group Product & Tech Conference в рекордно сжатые сроки.
В последнее время такие компании, как Google и Facebook, прилагают большие усилия в области развития кроссплатформенной разработки. Flutter и Kotlin/Native — это результаты этих усилий.
Что такое Flutter?
Flutter, разработанный Google, был анонсирован ещё в 2017 году. В качестве языка разработки он использует Dart. Flutter поддерживает компиляцию кода как на Android, так и на iOS, используя одну кодовую базу, написанную на Dart. Flutter компилируется в нативный код, а не использует web view-компоненты в приложениях. Но он использует свои собственные компоненты пользовательского интерфейса вместо специфических для конкретной платформы типа UIView в iOS или Fragments и ViewGroups в Android. Flutter также поддерживает Material Design и Material Theming в своих компонентах пользовательского интерфейса.
Опыт разработки на Dart у нас отсутствовал, поэтому мы не были уверены, что у нас будет достаточно времени, чтобы изучать новый язык (ведь у нас были и другие приоритетные задачи). Мы действительно не начали использовать Flutter, пока не поняли, что у нас реально мало времени. Поэтому изначально мы начали с использования Kotlin/Native и разработали некоторые макетные данные и логику для них.
Вот такая вот структура папок в Kotlin/Native у нас была:
Обратите внимание на папку «common», в которую помещается весь общий код, написанный на Kotlin. Соответственно проекты на Android и iOS используют код из этой папки.
Что такое Kotlin/Native?
Kotlin/Native разработан компанией JetBrains, той же компанией, которая создала и Kotlin. Если вы не слышали о Kotlin, возможно, вы просто в последнее время не заходили в интернет. В целом, это упрощнная замена Java, которая к тому же поддерживает обратную совместимость с ней же. Kotlin/Native позволяет писать код на Kotlin и компилировать его на различных платформах, которые изначально не поддерживают Kotlin, например, iOS.
Дизайн
Мы попросили нашего дизайнера накидать какой-нибудь макет для приложения, и она при помощи Material Theming быстренько выдала приятный дизайн. В Sketch есть плагин для создания Material Theming эскизов, что здорово сэкономило нам много времени и усилий.
Вот небольшой обзор Sketch-эскизов, сделанных нашим дизайнером:
Material Theming позволяет быстро создавать дизайн-макеты и поддерживает как iOS, так и Android.
Изначально мы хотели реализовывать пользовательский интерфейс отдельно для Android и iOS. Несмотря на то, что обе платформы поддерживают Material Theming, нам всё равно пришлось бы писать интерфейсы для обеих. И мы подумали, что если мы будем использовать Flutter для пользовательского интерфейса, то кодовая база для него у нас будет одна и она будет независима от логики приложения, и соответственно мы сможем продолжать использовать логику Kotlin независимо от этого.
Учим Kotlin/Native и Flutter работать вместе
Т.к. до этого мы с Flutter не работали, нам нужно было убедиться, что он будет работать с существующим кодом, который у нас уже есть. Кстати, похоже, что до этого никто не пытался использовать Flutter и Kotlin/Native вместе. Мы планировали построить архитектуру, представленную ниже. Эта архитектура уменьшает количество специфичного для каждой платформы кода, а также уменьшает количество кода на Dart, т.к. мы можем изолировать большую часть логики, используя Kotlin.
Мы смогли уменьшить количество специфического кода, используя Kotlin и Dart. Т.к. мы больше были знакомы с Kotlin, то большую часть общего кода писали на нём, а не на Dart.
Ограничения
В обеих этих технологиях есть определённые ограничения, которые делают их использование не таким простым, каким оно могло быть.
Ограничение 1: Kotlin/Native поддерживает только Kotlin-классы для общего кода. Например, если бы вы хотели использовать java.util.Date, то у вас не было бы такой возможности, т.к. для него требуется JVM. Один из способов решения такой проблемы — реализовать этот метод в коде платформ (Android и iOS) и вызывать его из Kotlin/Native.
Ограничение 2: Kotlin использует объекты Companion для статических методов, которые превращаются в совершенно новый объект в iOS. Один из способов обойти это — делать статические методы методами экземпляра или делать метод класса глобальной функцией.
Ограничение 3: Kotlin/Native поддерживает компиляцию только для arm64 на iOS. Последние устройства работают именно с этой архитектурой процессора, но старые — по-прежнему на armv7. Чтобы избежать каких-то проблем с архитектурой, просто перейдите в «Настройки сборки» и удалите все архитектуры, кроме arm64.
Существуют также некоторые ограничения при взаимодействии между кодом на Kotlin, кодом Flutter и кодом платформ. Flutter может взаимодействовать с кодом платформ, используя каналы, передавая туда имя метода и набор параметров. Параметры ограничены нативными классами, такими как map, list, string, int и т.д. При всём этом взаимодействии пользовательские объекты сериализуются. Однако и Flutter, и Kotlin/Native достаточно ограниченно поддерживают сериализацию, поэтому пока мы используем нативные классы напрямую.
Итоги
Ключевые результаты нашего опыта:
На разработку приложения ушло около недели планирования и полторы недели разработки. Мы тратили на это около часа в день с четырьмя разработчиками и дизайнером, параллельно выполняя свою обычную работу.
Было очень весело разрабатывать это приложение, используя Flutter и Kotlin, и я надеюсь, что вы тоже опробуете эти две технологии.
Вы можете найти больше материалов по Kotlin/Native в официальной документации:
Интернационализация и локализация приложения на Kotlin/Native
こんにちは, или добрый день по-японски.
Как бы не был популярен английский язык, всё же пользователям комфортнее и привычнее в родной языковой среде.
Поэтому далее мы пошагово рассмотрим процесс адаптации консольного приложения для Linux на Kotlin/Native к русской и английской локали.
Поможет нам в этом старый-добрый GNU gettext.
В итоге убедимся, что это совсем не страшно.
Заодно посмотрим интеграцию с библиотеками на C, которая значительно расширяет возможности Kotlin/Native.
Что напишем: переводчик количественных числительных на японский язык.
Что ожидается от читателя: знание языков программирования Kotlin, C, базовый уровень знакомства с ОС Linux (в частности Bash).
Что понадобится в процессе: любой дистрибутив Linux, любая версия IntelliJ IDEA, установленный пакет gettext-devel или аналогичный.
Мотивация
Где-то полгода медленно и печально изучаю японский язык по учебнику “Minna no Nihongo”: частью ради перевода текста песен, частью просто из интереса к культуре.
Позже решил перейти с системной разработки на прикладную, с десктопа на мобильные платформы, соответственно с C++/Qt/STL на Kotlin/JVM/Android SDK.
Теперь хочу два этих занятия совместить, написав для себя программы для помощи в изучении японского. Конечно, уже много готовых, но NIH-синдром ведь не что-то плохое, правда?
Раньше я не задумываюсь использовал бы связку Qt/QML/C++: она позволяет быстро и эффективно решать в общем-то любые задачи и на любой платформе.
Однако Qt всё больше поворачивается спиной к Open Source, вот и решил пора валить попробовать что-то другое.
И тут в процессе изучения Kotlin узнал про Kotlin/Native.
Соответственно, первая программа-помощник будет именно на нём.
Что такое Kotlin/Native
Изначально Kotlin выступал в качестве «более лучшей» (С) Java, и целиком опирался на платформу JVM.
Однако затем компания JetBrains, разработчик Kotlin, решила адаптировать набирающий популярность язык и под другие платформы.
В частности, под веб (Kotlin/JS) и под «натив» (Kotlin/Native).
Kotlin/Native появился в марте 2017 года, кстати ровно четыре года назад.
Он позволяет компилировать код на Kotlin в нативный код с помощью LLVM, без зависимости от виртуальной машины JVM и других библиотек.
Далее мои субъективные впечатления по опыту разработки демонстрационного приложения, так что буду рад исправлениям и дополнениям.
исходный код под пермиссивной открытой лицензией (Apache-2.0 license)
работа на всех поддерживаемых LLVM платформах, в частности iOS и десктопы
генерирует единственный исполняемый файл без сторонних зависимостей
низкое потребление системных ресурсов
доступны все базовые «вкусности» Kotlin вроде коллекций и функционального программирования
есть прозрачный interop с языком C
как следствие: доступны low-level функции платформы, в частности POSIX
стандартная библиотека весьма бедная по сравнению с огромной JVM, многое придётся писать с нуля (пример: оставьте только пункт Native тут)
нет стабильной библиотеки для GUI, хотя есть некоторые привязки через C interop (GTK, libui)
слабый инструментарий по сравнению с той же Android Studio, например нет той же локализации
относительно долгое время сборки
Больше о Kotlin/Native можно почитать тут, а примеры доступны на Github.
Терминология
Интернационализация (i18n): подготовка приложения к локализации, обычно выполняется разработчиками.
Локализация (l18n): Процесс перевода и адаптации контента приложения для конкретных языков, обычно выполняется переводчиками.
Важно: «контент» тут это не только строки, но и направление текста, формат даты, чисел и так далее. В данной статье ограничусь только строками.
Что такое GNU gettext
Этот пакет из нескольких утилит, библиотек и регламентов.
правила оформления исходного кода для последующей интернационализации
утилиты для генерации текстовых файлов с локализуемыми строками
кроссплатформенная нативная библиотека для извлечения переводов в runtime
правила дистрибуции бинарных файлов с переводами
Почему GNU gettext
Интернационализация в Kotlin/JVM для Android использует средства Android SDK, в частности строковые ресурсы, и завязана на JVM.
Поэтому для Kotlin/Native эти средства недоступны.
В Qt есть собственный инструментарий, но его не получится использовать вне Qt, тем более с отличным от C++ языком.
Поэтому остаётся GNU gettext:
универсальный (поддерживается множество языков программирования)
кроссплатформенный (Win/Mac/Linux, есть Android/iOS версия)
стабильный в силу почтенного возраста
Демонстрационный проект
Суть: консольная программа пока только под Linux, чтобы не переусложнять код.
Функционал: читает натуральное число из аргумента командной строки или stdin, и переводит его в количественное числительное на японском.
Число может содержать специфичные для локали разделители тысяч, которая программа выводит при запуске.
Скачать проект можно на Github и затем открыть в IntelliJ IDEA.
Характеристики исполняемых файлов
Для начала время полной сборки:
18 сек на конфигурации Ryzen 3900X + 32GB DDR4-3600 + NVM-E SSD. На мой взгляд многовато для такого маленького проекта и такой конфигурации.
Тут можно вспомнить о преимуществах скриптовых языков, которые компилировать не надо.
Теперь посмотрим свойства исполняемого файла для отладочной и релизной конфигураций:
Размеры скомпилированных исполняемых файлов
Тут всё в порядке, бинарники скромные по размеру и без каких-либо сторонних зависимостей.
Отладка проекта
Она не работает, по крайней мере в Community Edition.
Просто игнорируются точки останова, хотя судя по выводу команды file отладочные символы в исполняемом файле есть.
Насколько я понял, соответствующий плагин доступен только в платной редакции IDE, которая пока для меня избыточна.
Прошу поправить, если ошибаюсь.
Так что для написания демо пришлось обходиться printf-driven отладкой, ну мне не привыкать после Android AOSP.
Интернационализация
В случае нашего проекта нужно лишь все локализуемые строки «обернуть» в вызов функции gettext().
Для краткости можно сделать синоним этой функции, например tr(), это общепринятая практика.
Понадобится ещё служебный код для работы с POSIX-локалями, он находится в файле Locale.kt.
Также мы должны заранее определиться с количеством поддерживаемых языков: для демо это будут только английский и русский, плюс числительные на японском для любого языка.
Перевод локализуемых строк
Я написал Bash-скрипты для генерации с нуля и обновления файлов gettext:
Далее вкратце опишу основные шаги, которые они выполняют.
Генерируем pot-файл («шаблон»), который содержит базовую информацию о программе и собственно строки нуждающиеся в переводе.
Генерируем po-файл (текстовый перевод):
Генерируем mo-файл (бинарный перевод):
Развертывание бинарных файлов с переводами
К сожалению, Kotlin/Native не поддерживает ресурсы, так что «упаковать» mo-файлы в исполняемый файл пока не выйдет.
На это есть соответствующий баг.
Думаю, функционал ресурсов можно реализовать и вручную дополнительной задачей в Gradle, это пожалуй тема для отдельной статьи.
Для тестового проекта положим mo-файлы рядом с приложением, где не нужны права суперпользователя и где gettext сможет их найти.
Как видите, процесс несложен, по крайней мере при наличии готового кода и скриптов.
Русские Блоги
Kotlin Native актуальная разработка
Примечание. Эта часть контента взята из «Kotlin Introduction and Actual Combat», которая, как ожидается, будет доступна в сентябре.
16.1 Kotlin Native
16.1.1 Введение в Kotlin Native
Прежде чем объяснять конкретные знания Kotlin Native, давайте взглянем на две общие школы компьютерных языков высокого уровня: компилируемые языки и интерпретируемые языки.
Так называемый скомпилированный язык относится к использованию специального компилятора для компиляции исходного кода определенного высокоуровневого языка для конкретной платформы / операционной системы в машинный код, который может одновременно выполняться оборудованием платформы. Скомпилированная исполняемая программа может быть отделена от среды разработки. Работайте независимо на конкретной платформе. Поскольку скомпилированные языки компилируются в машинный код одновременно, они могут работать независимо от среды разработки и обычно работают более эффективно. Однако, поскольку скомпилированные языки могут быть скомпилированы в машинный код только на определенной платформе, сгенерированные исполняемые программы обычно не переносятся для запуска на других платформах. Например, все более популярные языки программирования высокого уровня, такие как C и C ++, являются компилируемыми языками.
Так называемый интерпретируемый язык относится к языку программирования, который использует специальный интерпретатор для построчной интерпретации исходной программы, генерирует машинный код для конкретной платформы и немедленно выполняет его. Интерпретируемые языки обычно не требуют общей компиляции и обработки ссылок. Интерпретируемые языки будут смешивать процессы компиляции и интерпретации в компилируемых языках для выполнения. Хотя эффективность работы интерпретируемого языка низка и он не может работать независимо от интерпретатора, интерпретируемый язык может легко реализовать трансплантацию и работу исходной программы.
## 16.1.2 Kotlin Native Compiler В настоящее время Kotlin Native в основном предоставляет компиляторы для трех основных платформ Mac, Linux и Windows. С помощью этого компилятора вы можете легко компилировать и запускать Программы для систем Raspberry Pi, iOS, OS X, Windows и Linux. Kotlin Native поддерживает платформы и версии, как показано в таблице ниже.
Таблица 16-1 Платформы, поддерживаемые Kotlin Native, и их версии
Чтобы скомпилировать проект Kotlin Native, вам сначала необходимо загрузить пакет компилятора Kotlin Native с Github. Адрес загрузки:github.com/JetBrains/k… Программный пакет собственного компилятора, структура его каталогов показана на рисунке 16-1.
Рис. 16-1. Схема структуры каталогов компилятора Kotlin Native Конечно, вы также можете выполнить компиляцию путем клонирования исходного кода компилятора Kotlin Native, и компиляция должна быть первой. Загрузите исходный код компилятора на Github, адрес загрузки:github.com/JetBrains/k…
Затем установите связь между компилятором и библиотекой.
Если вам нужно собрать весь проект, это может занять много времени. Затем используйте следующую команду для компиляции проекта.
Если вам нужно протестировать приложение, вы можете использовать команду, подобную следующей.
Можно обнаружить, что рабочая среда Kotlin Native compiler konan по-прежнему нуждается в поддержке среды JVM, но исполняемая программа машинного кода, которую она генерирует, не требует поддержки среды JVM и может запускаться непосредственно в системе соответствующей платформы.
16.2 Родные примеры Kotlin
## 16.2.1 Сборка собственного проекта Kotlin Сначала выберите в IDEA [Файл] → [Создать] → [Проект], чтобы создать обычный проект Gradle.
Рис. 16-4. Создание проекта Gradle ## 16.2.2 Добавление конфигурации подключаемого модуля konan После завершения создания Необходимо изменить конфигурацию файла build.gradle. Откройте файл build.gradle и добавьте следующую конфигурацию.
На этом этапе вам также необходимо создать файл kotliner.def, который в основном используется для настройки сопоставления между исходным кодом C и Kotlin.
## 16.2.3 Написание исходного кода Затем создайте новый каталог c в каталоге src проекта, который используется для хранения кода C. Сначала создайте два файла c: cn_kotliner.h и cn_kotliner.c. Среди них код, объявленный заголовочным файлом C, выглядит следующим образом.
В приведенном выше коде в основном объявлены две функции: функция printHello для печати HelloWorld и функция факториала для вычисления факториала. Исходный код cn_kotlinor.c выглядит следующим образом:
Затем вам также необходимо создать файл kotlin, который в основном предназначен для вызова кода уровня C для реализации кроссплатформенных вызовов. Исходный код этого файла выглядит следующим образом:
Рис. 16-5. Схема структуры каталогов проекта Kotlin Native.
## 16.2.4 Добавление конфигурации konanInterop и konanArtifacts Затем вам также необходимо добавить информацию о конфигурации, относящуюся к konanInterop и konanArtifacts. Среди них konanInterop в основном используется для настройки интерфейса Kotlin для вызова C. Соответствующий исходный код выглядит следующим образом:
В дополнение к параметрам, использованным выше, konanInterop также предоставляет следующие часто используемые параметры.
Конкретные значения параметров конфигурации konanInterop показаны в следующей таблице.
Таблица 16-2. Таблица описания параметров конфигурации konanInterop Затем вам необходимо добавить в проект конфигурацию, связанную с konanArtifacts, которая в основном используется для обработки выполнения задач компиляции.
16.2.5 Скомпилировать и выполнить
Затем в каталоге src / c проекта используйте командную строку для компиляции приведенного выше кода, команда выглядит следующим образом.