Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 05 Jun 2019 10:53:33 +0000
From:      bugzilla-noreply@freebsd.org
To:        ports-bugs@FreeBSD.org
Subject:   [Bug 236805] [NEW PORT] lang/elm: Delightful language for reliable webapps
Message-ID:  <bug-236805-7788-y0w3KqeTMS@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-236805-7788@https.bugs.freebsd.org/bugzilla/>
References:  <bug-236805-7788@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236805

Kamila Sou=C4=8Dkov=C3=A1 <kamila@ksp.sk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kamila@ksp.sk
 Attachment #204835|                            |maintainer-approval?(glorie
              Flags|                            |ux@pm.me)

--- Comment #8 from Kamila Sou=C4=8Dkov=C3=A1 <kamila@ksp.sk> ---
Created attachment 204835
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D204835&action=
=3Dedit
elm-lang.shar -- fixed to build under Poudriere with network, but still doe=
sn't
build by default

I made small changes to the port, so that it at least builds under Poudriere
with ALLOW_NETWORKING_PACKAGES=3D"elm-lang" (previously it did not, as caba=
l was
trying to write to a non-existent directory). This way it can at least be
built, and afterwards the packaged binary works as expected.

Me and Evilham (subscribed) spent quite a bit of effort trying to make this
build without network, but we were not successful. The reason is that the
Haskell bits are throwing logs under our feet: cabal does not actually real=
ly
resolve dependencies until it tries to build things. Therefore, moving fetc=
hing
of dependencies into the fetch part without also moving the build itself th=
ere
doesn't work.

The workaround used in other Haskell packages is to manually figure out the
right dependencies and use the substantial machinery in Mk/Uses/cabal.mk. T=
his
is, unfortunately, also not quite usable, because cabal.mk assumes that the
package in question is on Hackage, which Elm is not (well it is, but it is =
very
much out of date). Evilham might be able to provide more details on this. I
believe that the best way to make a "proper" port out of this would be to
update the Elm package on Hackage, and do it the cabal.mk way.

Would the elm people be willing to add up-to-date Elm to Hackage? If yes, we
could ask the FreeBSD Haskell folks for help and hopefully make this work a=
nd=20
get it committed.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-236805-7788-y0w3KqeTMS>