Brett Gilio <bre...@posteo.net> writes: > Greetings all! > > I am continuing my prolific streak of trying to move as many things from > my channel to the main repository as possible. > > Up next on the menu: the Mercury language and compiler. > http://mercurylang.org/ > > So here are a few issues I am wanting to get resolved with this package, > and I am hoping some support from the community can get this package > further along. > > 1. Mercury comes with a number of "grades", which you can think of as > anything relating to do with support for extra backends, libraries, and > a number of other functionalities. The default setting in Mercury is to > compile the compiler including all of the standard grades, which can > take one heck of a long time! As a result, I was thinking of adopting > something similar to `emacs-minimal`, for people who need to use the > Mercury compiler but do not need all of that overhead of having all of > the grades included by default. > > (define-public mercury-minimal > (package (inherit mercury) > (name "mercury-minimal") > (build-system gnu-build-system) > (arguments > (substitute-keyword-arguments (package-arguments mercury) > ((#:configure-flags flags ''()) > `(list "--enable-minimal-install")))) > (inputs > `(("gcc-toolchain" ,gcc-toolchain))) > (synopsis "A pure logic programming language (used only for > compiling packages dependent on base Mercury)"))) > > > So this example comes with a few points I want to address. Most distinct > is the modification of the inherited mercury args to use the > minimal-install flag (disabling grades not related to the compiler > itself). Additionally, to use the mercury compiler in projects it > depends on having some C-based toolchain to handoff the extracted code > to. Is including gcc-toolchain as an Input/Prop-Input the best solution > here? I worry that it might conflict with versions of the toolchain > already in a user profile, or if somebody wants to use a different > version of the gcc-toolchain (though they could replace the input using > the appropriate guix flag.) > > 2. The Mercury source tarball includes a git submodule copy of > boehm-gc. Of course, I think the "Guix way"TM of doing this is to strip > out the submodule and replace it using a Native-Input (assuming the two > versions are compatible, anyways). Here is the method I have assumed for > trying to get that done. > > (add-after 'unpack 'replace-boehm > (lambda* (#:key inputs #:allow-other-keys) > (let ((boehm (assoc-ref inputs "libgc"))) > (map (match-lambda > ((src orig-name new-name) > (with-directory-excursion "." > (apply unpack (list #:source src)) > (apply patch-source-shebangs (list #:source src))) > (delete-file-recursively new-name) > (invoke "mv" orig-name new-name))) > `((,boehm "source" "libgc")))))) > > > Now, this code may not be perfectly correct (feel free to do the work > for me here, if you want, but I can probably figure it out ;). But, the > code is at least in the spirit of what I am trying to achieve here. The > issue here may just be that I am tired, but for whatever reason > `match-lambda' is not resolving. > > starting phase `replace-boehm' > Backtrace: > 8 (primitive-load "/gnu/store/z0wfywmlbn079q07hgab4fafmqx…") > In ice-9/eval.scm: > 191:35 7 (_ #f) > In ice-9/boot-9.scm: > 829:9 6 (catch srfi-34 #<procedure 7ffff2d1a420 at /gnu/store/…> …) > In srfi/srfi-1.scm: > 863:16 5 (every1 #<procedure 7ffff2d1a3e0 at /gnu/store/w3jlc8p…> …) > In > /gnu/store/w3jlc8pk8416m7h677r5vq92b66h8cqd-module-import/guix/build/gnu-build-system.scm: > 839:30 4 (_ _) > In ice-9/eval.scm: > 159:9 3 (_ #(#(#(#<directory (guile-user) 7ffff3c6b140>) (…)) #)) > 182:19 2 (proc #(#(#(#<directory (guile-user) 7ffff3c6b140>) …) …)) > 142:16 1 (compile-top-call _ (7 . match-lambda) ((10 (10 # …) …))) > In unknown file: > 0 (%resolve-variable (7 . match-lambda) #<directory (guil…>) > > ERROR: In procedure %resolve-variable: > Unbound variable: match-lambda > > > Last I checked, match-lambda belongs to `(ice-9 match)`. Though it is > very possible that there is just some syntactical issue here that I am > just not seeing right now. Again, eyes on this would be appreciated :). > > 3. Last, but not least: If any of you can find documentation on how to > run the tests for the Mercury compiler, I would greatly appreciate it! I > am completely lost on how to run them. I can not find an appropriate > make target for them to run off of. > > 4. This one is not a real issue, per se; however, so far I am doing this > work in a new module (gnu packages mercury). I would have preferred to > place this in a (gnu packages prolog), but we only have a (gnu packages > gprolog) named for the GNU implementation. I personally find this naming > convention unfortunate, as I have SWI-Prolog packaged in my channel too, > and I would like to see SWI-Prolog, gprolog, and mercury all reside in > an appropriately named module. > > Alright, hopefully this is enough information to get some help but not > too much for you all to not eventually consider me for maintainer status > in the project. Haha. > > Below is the complete WIP for Mercury. All thoughts, criticism, and > confused stares are welcome: > > (define-public mercury > (package > (name "mercury") > (version "14.01.1") > (source (origin > (method url-fetch) > (uri (string-append > "https://dl.mercurylang.org/release/mercury-srcdist-"; > version > ".tar.gz")) > (sha256 > (base32 > "12z8qi3da8q50mcsjsy5bnr4ia6ny5lkxvzy01a3c9blgbgcpxwq")))) > (build-system gnu-build-system) > (arguments > '(#:tests? #f ; TODO: tests are cryptic. Figure it out later. > #:phases > (modify-phases %standard-phases > (add-after 'unpack 'patch > (lambda _ (substitute* > (list "Makefile" > "Mmakefile" > "scripts/mercury_update_interface.in" > "scripts/mercury_config.in" > "scripts/mmake.in" > "scripts/mmake.sh" > "scripts/Mmake.vars.in" > "scripts/mdb.in" > "scripts/rs6000_hack" > "scripts/fullarch" > "scripts/mmc.in" > "scripts/canonical_grade" > "scripts/mprof.in" > "scripts/gud.el" > "scripts/ml.in" > "scripts/canonical_grade.in" > "scripts/mdprof.in" > "scripts/vpath_find" > "scripts/mkfifo_using_mknod.in" > "scripts/prepare_install_dir.in" > "scripts/ml.sh" > "scripts/mprof_merge_runs" > "scripts/mtc" > "scripts/mgnuc.in" > "scripts/c2init.in" > "bindist/bindist.Makefile") > (("/bin/sh") (which "sh")) > (("/bin/pwd") (which "pwd")) > (("/bin/rm") (which "rm"))))) > (add-after 'unpack 'replace-boehm > (lambda* (#:key inputs #:allow-other-keys) > (let ((boehm (assoc-ref inputs "libgc"))) > (map (match-lambda > ((src orig-name new-name) > (with-directory-excursion "." > (apply unpack (list #:source src)) > (apply patch-source-shebangs (list #:source src))) > (delete-file-recursively new-name) > (invoke "mv" orig-name new-name))) > `((,boehm "source" "libgc"))))))))) > (native-inputs > `(("texinfo" ,texinfo) > ("flex" ,flex) > ("tcsh", tcsh) > ("bison" ,bison) > ("readline" ,readline) > ("libgc" ,libgc))) > (synopsis "A pure logic programming language") > (description "Mercury is a logic/functional programming language which > combines the clarity and expressiveness of declarative programming with > advanced > static analysis and error detection features. Its highly optimized execution > algorithm delivers efficiency far in excess of existing logic programming > systems, and close to conventional programming systems. Mercury addresses > the problems of large-scale program development, allowing modularity, > separate compilation, and numerous optimization/time trade-offs.") > (home-page "https://mercurylang.org";) > (license license:gpl2))) > > (define-public mercury-minimal > (package (inherit mercury) > (name "mercury-minimal") > (build-system gnu-build-system) > (arguments > (substitute-keyword-arguments (package-arguments mercury) > ((#:configure-flags flags ''()) > `(list "--enable-minimal-install")))) > (inputs > `(("gcc-toolchain" ,gcc-toolchain))) > (synopsis "A pure logic programming language (used only for > compiling packages dependent on base Mercury)")))
Hey all! Just bumping this as I had not heard anything yet. -- Brett M. Gilio https://git.sr.ht/~brettgilio/
