13. Запуск GHC на системах Win32

13.6.1. Общие сведения

Инструменты Cygwin стремятся предоставить API в стиле Unix поверх библиотек Windows для облегчения переноса Unix-приложений на Windows. Для этого они вводят иерархию каталогов в стиле Unix под некоторым корневым каталогом (обычно / — это C:\cygwin\). Кроме того, всё, что создано на основе API Cygwin (включая инструменты Cygwin и программы, скомпилированные с помощью GHC Cygwin), будет видеть / как корень своей файловой системы, имитируя работу в обычной Unix-среде и находя такие вещи, как /bin и /usr/include, не заботясь при этом об их фактическом расположении в системе Windows (вероятно, C:\cygwin\bin и C:\cygwin\usr\include).

13.6.2. Проблема

GHC по умолчанию больше не зависит от cygwin, а является собственной программой Windows. Он создаётся с использованием mingw и использует mingw’s GHC при компиляции ваших Haskell-источников (даже если вы вызываете его из bash Cygwin), но здесь важно то, что, как и любая другая обычная программа Windows, ни GHC, ни создаваемые им исполняемые файлы не осведомлены о вымышленной Unix-иерархии Cygwin. GHC будет спокойно принимать как /, так и \\ в качестве разделителей путей, но не будет знать, где найти /home/joe/Main.hs или /bin/bash и т. п. Это приводит к всяческим проблемам, когда GHC используется из bash Cygwin или в сессиях make, выполняемых под Cygwin.

13.6.3. Действия

• Не используйте абсолютные пути в make, configure и т. д., если есть вероятность, что они могут быть переданы GHC (или программам, скомпилированным GHC). Относительные пути подходят, поскольку инструменты cygwin с ними работают, а GHC принимает / в качестве разделителя путей. И относительные пути не зависят от того, где находится корневой каталог Cygwin, или на каком разделе или сетевом диске расположен ваш исходный код, если вы cd туда сначала.
• Если вам необходимо использовать абсолютные пути (остерегайтесь бессовестного ROOT=$(pwd) в иерархиях make или скриптах configure), Cygwin предоставляет инструмент под названием cygpath, который может преобразовать пути Cygwin в стиле Unix в их эквиваленты в стиле Windows. Многие инструменты Cygwin фактически принимают абсолютные пути в стиле Windows (вспомните, что вам либо нужно экранировать \\ или преобразовать \\ в /), поэтому вы можете просто использовать их везде. Если вам нужны инструменты, которые выполняют какие-либо манипуляции с путями, зависящими от путей в стиле Unix (например, попытка интерпретировать : как разделитель в списках путей), вы всё ещё можете попробовать преобразовать пути с помощью cygpath перед тем, как передать их GHC и т. п.

• Если у вас нет cygpath, у вас, вероятно, нет cygwin, и, следовательно, нет проблем с ним… если только вы не захотите написать одну сборку для нескольких платформ. Опять же, относительные пути — ваши друзья, но если вам нужно использовать абсолютные пути и не хотите использовать разные инструменты на разных платформах, вы можете просто написать небольшую Haskell-программу для вывода текущей директории (спасибо George Russell за эту идею): скомпилированная с помощью GHC, она даст вам представление о файловой системе, от которой зависит GHC (которое будет отличаться в зависимости от того, скомпилирован ли GHC с gcc cygwin или mingw или на реальной Unix-системе..) - эта небольшая программа также может обрабатывать экранирование \\ в путях. Помимо баннера и времени загрузки, что-то вроде этого также будет:

  $ echo "Directory.getCurrentDirectory >>= putStrLn . init . tail . show " | ghci
  

13.7.1. Создание DLL-библиотеки

Создание DLL-библиотеки Win32 - упаковка вашей Haskell-библиотеки в DLL проста; скомпилируйте объектные файлы, составляющие библиотеку, а затем создайте DLL, выполнив команду в формате:

ghc -shared -o foo.dll bar.o baz.o wibble.a -lfooble

Передавая компилятору ghc опцию -shared, он создаст DLL-библиотеку вместо исполняемого файла. DLL будет состоять из всех объектных файлов и архивов, указанных в командной строке.

Несколько замечаний:

• По умолчанию, точки входа всех объектных файлов будут экспортированы из DLL при использовании -shared. Если вы хотите ограничить это, вы можете указать файл определения модуля для использования в командной строке следующим образом:

  ghc -shared -o .... MyDef.def
  

  См. документацию Microsoft для получения подробностей, но файл определения модуля просто перечисляет точки входа, которые вы хотите экспортировать. Вот один, подходящий для создания DLL-сервера COM Haskell:

  EXPORTS
   DllCanUnloadNow     = DllCanUnloadNow@0
   DllGetClassObject   = DllGetClassObject@12
   DllRegisterServer   = DllRegisterServer@0
   DllUnregisterServer = DllUnregisterServer@0
  

• В дополнение к созданию DLL, опция -shared также создает библиотеку импорта. Имя библиотеки импорта выводится из имени DLL следующим образом:

  DLL: HScool.dll  ==> import lib: libHScool.dll.a
  

  Схема именования может показаться немного странной, но она предназначена для обеспечения сосуществования библиотек импорта с обычными статическими библиотеками (например, libHSfoo.a и libHSfoo.dll.a. Кроме того, когда компилятор связывает нестатически, он перепишет вхождение -lHSfoo в командной строке на -lHSfoo.dll. Сделав это за вас, переход от нестатической к статической компоновке сводится к добавлению -static в вашу командную строку.

13.7.2. Создание DLL-библиотек для вызова из других языков

Этот раздел описывает, как создавать DLL-библиотеки, которые можно вызывать из других языков, таких как Visual Basic или C++. Это частный случай Создание Haskell-библиотеки, которую можно вызывать из внешнего кода; ниже мы рассмотрим возникающие проблемы, специфичные для DLL. Вот пример:

Используйте объявления внешнего экспорта для экспорта функций Haskell, которые вы хотите вызывать извне. Например:

-- Adder.hs
{-# LANGUAGE ForeignFunctionInterface #-}
module Adder where

adder :: Int -> Int -> IO Int  -- gratuitous use of IO
adder x y = return (x+y)

foreign export ccall adder :: Int -> Int -> IO Int

Добавьте некоторый вспомогательный код, который запускает и завершает Haskell RTS:

// StartEnd.c
#include <Rts.h>

void HsStart()
{
   int argc = 1;
   char* argv[] = {"ghcDll", NULL}; // argv must end with NULL

   // Initialize Haskell runtime
   char** args = argv;
   hs_init(&argc, &args);
}

void HsEnd()
{
   hs_exit();
}

Здесь Adder - имя корневого модуля в дереве модулей (как упоминалось выше, должен быть один корневой модуль, и, следовательно, одно дерево модулей в DLL). Скомпилируйте всё:

ghc -c Adder.hs
ghc -c StartEnd.c
ghc -shared -o Adder.dll Adder.o Adder_stub.o StartEnd.o

Теперь файл Adder.dll можно использовать из других языков программирования. Перед вызовом любых функций в Adder необходимо вызвать HsStart, а в самом конце вызвать HsEnd.

Private Declare Function Adder Lib "Adder.dll" Alias "adder@8" _
      (ByVal x As Long, ByVal y As Long) As Long

Private Declare Sub HsStart Lib "Adder.dll" ()
Private Declare Sub HsEnd Lib "Adder.dll" ()

Private Sub Document_Close()
HsEnd
End Sub

Private Sub Document_Open()
HsStart
End Sub

Public Sub Test()
MsgBox "12 + 5 = " & Adder(12, 5)
End Sub

// Tester.cpp
#include "HsFFI.h"
#include "Adder_stub.h"
#include <stdio.h>

extern "C" {
    void HsStart();
    void HsEnd();
}

int main()
{
    HsStart();
    // can now safely call functions from the DLL
    printf("12 + 5 = %i\n", adder(12,5))    ;
    HsEnd();
    return 0;
}

$ ghc -o tester Tester.cpp Adder.dll.a
$ tester
12 + 5 = 17