Вот кое-что для начала. Надеюсь, это поможет вам в правильном направлении.
Когда вы используете библиотеку в георадаре, я знаю 3 случая.
Имейте в виду, что это не полный ответ, наверняка существует больше случаев, и я могу забыть некоторые вещи. Эта тема подвержена ошибкам, поэтому вам следует больше покопаться в межсетевых страницах, документации AdaCore / GNAT и потоке стека, так как эта тема часто поднимается. Некоторые из указанных ловушек могут быть не рассмотрены здесь, в зависимости от типа библиотек, которые вы имеете / производите, и некоторых конкретных параметров компиляции / сборки / ссылки.
Предисловие: когда вы включаете статическую библиотеку, ее единственное имя файла не говорит вам ничего полезного для вызова кода, который она содержит. Таким образом, если статической библиотекой является 'serivices.a', это просто имя файла и расширение. with Services.A недостаточно для вызова кода.
Дело 1
У вас есть доступ к GPR my_lib.gpr, который создает библиотеку, и она написана на языке Ада.
Просто включите GPR, и в вашем коде вам будет разрешено только with открытые интерфейсы. (это соответствует комментарию Саймона Райта о with "services.gpr"; в вашем GPR)
- если
my_lib.gpr создает статическую библиотеку, больше ничего не делать! GPR делает то, что вам нужно (сборка / ссылка).
- если библиотека динамическая (dll), то dll необходимо найти во время выполнения в пути поиска ОС (рядом с исполняемым файлом или в переменной окружения пути)
Дело 2
У вас есть доступ к GPR my_lib.gpr, который создает библиотеку, и она написана на другом языке.
- сборка библиотеки
- определяет другой GPR
my_lib_install.gpr, который содержит объявления интерфейса библиотеки (.ads файлы). Если файлы не существуют, см. Дело 3 .
- ссылка на GPR в ваш собственный проект GPR
- теперь вы можете использовать методы / типы, определенные в файлах
.ads в вашем коде. .ads обычно содержит pragma Import(...) декларацию соглашения. Они определяются один раз, поэтому сообщение об ошибке unit "Services.A" cannot belongs to several projects отсутствует.
Или вы можете напрямую включить декларации интерфейса библиотеки (.ads файлы) в ваш проект.
- если
my_lib.gpr создает статическую библиотеку, вы должны включить соответствующие директивы ссылки для использования файла .a.
- если библиотека динамическая (dll), тогда dll нужно найти во время выполнения в пути поиска ОС (рядом с исполняемым файлом или в переменной окружения пути)
Дело 3
Библиотека my_lib является COTS и написана на другом языке.
Поставляется с определением интерфейса.
Обычный метод - записать .ads файл (ы), соответствующий предоставленному определению контракта. Типы и методы должны быть помечены некоторым pragma Import(...) соглашением, соответствующим способу построения библиотеки (соглашение Ada, соглашение C, см. ARM или this wiki )
Обычно контракт интерфейса - это файл .h (большинство библиотек создаются с соглашением C). Таким образом, вы можете использовать пакеты Ada Interfaces.c, которые предназначены для этого. Пример взаимодействия с C приведен в в этом примере взаимодействия Ada с Java через соглашение C ). Основное отличие в том, что вы будете pragma Import вместо pragma Export
Это должно отвечать:
Есть ли официальные способы включить спецификации, такие как заголовок в C
из внешней статической библиотеки в ada?
Вы можете либо напрямую включить этот .ads файл (ы) в свои источники, либо написать свой собственный GPR для этого хостинга, как указано в начале. Это зависит от вас.
Последнее слово, если ваша библиотека написана на языке Ada, вы можете взглянуть на документацию, касающуюся усложнение , символы 'initialize' и 'finalize'.