В разделе документации Stack по многопакетным проектам есть немного об этом, но, к сожалению, он решает показать пример с использованием двух готовых пакетов, что приводит к путанице.
Общая идея состоит в том, чтобы поместить каталоги проектов mig и che в общий каталог проекта, а затем поместить в общий каталог один файл stack.yaml, в котором в качестве пакетов указаны mig и che. быть построенным (вместо обычного пакета "."). Зависимость в che.cabal от mig будет автоматически разрешена.
Вот полный, минимальный пример. Если вы запустите stack build в multi, он создаст che, затем mig и stack exec mig запустят программу.
Также обратите внимание, что если вы поместите два существующих каталога проекта Stack на место, я считаю, что вы должны удалить их локальные файлы stack.yaml и либо объединить содержимое вручную в один multi/stack.yaml, либо запустить stack init in multi для генерации свежих multi/stack.yaml из содержимого mig/mig.cabal и che/che.cabal. Должен быть только один stack.yaml для каждой коллекции проектов, создаваемых как единое целое.
мульти / stack.yaml
resolver: lts-13.26
packages:
- che
- mig
мульти / Che / che.cabal
name: che
version: 0.1.0.0
build-type: Simple
cabal-version: >=1.10
library
default-language: Haskell2010
exposed-modules: Che
build-depends: base >= 4.7 && < 5
мульти / Che / Che.hs
module Che where
che :: IO ()
che = putStrLn "Viva la revolution"
мульти / МИГ / mig.cabal
name: mig
version: 0.1.0.0
build-type: Simple
cabal-version: >=1.10
executable mig
default-language: Haskell2010
main-is: Main.hs
build-depends: base >= 4.7 && < 5
, che
мульти / МИГ / Main.hs
import Che
main :: IO ()
main = che >> che >> che
Обновление: разработка che самостоятельно
Обратите внимание, что даже если вы также работаете над самостоятельной разработкой / сборкой che, указанная выше установка multi будет рекомендованным способом настройки проекта mig. В частности, если вы хотите собрать che только без перестроения mig (например, если вы знаете, что mig будет сломан во время работы с che), вы можете использовать команду stack build che вместо stack build.
Если вы хотите продолжить разработку che, не вмешиваясь в версию che, используемую mig, то самое простое - сделать git clone новый репозиторий с рабочим каталогом и у вас может быть копия "bleeding edge" che (со своим отдельным отдельным пакетом stack.yaml), которую вы можете разрабатывать и создавать самостоятельно, и "стабильный" che, от которого зависит mig, который вы может git pull по мере необходимости. Будет хорошей идеей оставить stack.yaml вне Git, или назвать его stack.yaml.template или что-то еще и символическую ссылку или скопировать его в stack.yaml.
Если вы действительно хотите относиться к che так же, как Stack обрабатывает пакеты Stackage и имеет проект с одним пакетом для mig, который так или иначе зависит от глобального пакета che, то вы можете либо: (1) начать загрузку che в Stackage и обращаться с ним буквально, как с любым другим пакетом Stackage; или (2) добавьте extra_deps в файл stack.yaml для mig, который указывает на поддерживаемый глобальный источник пакета. Это может быть GitHub или другой веб-репозиторий ; это может быть «архив» (например, в формате .tar.gz, созданный с помощью git archive), хранящийся в локальной файловой системе; или даже Git-репозиторий в локальной файловой системе. Для этого последнего варианта абсолютные пути работают нормально, но я не думаю, что относительно пути поддерживаются напрямую. Это будет выглядеть примерно так:
# in mig's stack.yaml
extra-deps:
- git: /home/me/src/haskell/che
commit: 8ab4bf759dd934fa31cfca324748af894ca0e224