On 08/31/18 12:25, Fabian Raetz wrote:
On Fri, Aug 31, 2018 at 02:40:26PM +0200, Raphael Graf wrote:
Hi Fabian

On 08/31/18 02:00, Fabian Raetz wrote:
On Thu, Aug 30, 2018 at 06:49:34PM -0400, Brian Callahan wrote:
On 08/30/18 18:35, Brian Callahan wrote:
Hi Fabian --

On 08/30/18 17:28, Fabian Raetz wrote:
On Thu, Aug 30, 2018 at 05:12:35PM -0400, Brian Callahan wrote:
Hi Fabian --

On 08/30/18 16:42, Fabian Raetz wrote:
Hi all.

i've been using the "WebAssembly Binary Toolkit" lately and
thought i create a
proper port for it.

The port doesn't support running the tests as they require
some git submodules including
the gtest source. Sadly, my cmake skills are not good enough
to make the build system
use gtest from ports so i decided against it for the moment.

In case you wanna compile a small WebAssembly programm
yourself, take a look at
https://jameshfisher.com/2017/10/13/webassembly-hello-world.html

Cheers,
Fabian

HOMEPAGE: https://github.com/WebAssembly/wabt

DESCR:
WABT (we pronounce it "wabbit") is a suite of tools for
WebAssembly, including:

wat2wasm:     translate from WebAssembly text format to the
WebAssembly binary
                  format
wasm2wat:     the inverse of wat2wasm, translate from the
binary format back
          to the text format (also known as a .wat)
wasm-objdump:     print information about a wasm binary.
Similiar to objdump.
wasm-interp:     decode and run a WebAssembly binary file
using a stack-based
                     interpreter
wat-desugar:     parse .wat text form as supported by the
spec interpreter
                     (s-expressions, flat syntax, or mixed)
and print "canonical"
                     flat format
wasm2c:     convert a WebAssembly binary file to a C source and header


Is this different from the wabt port I ok'd here?
https://marc.info/?l=openbsd-ports&m=152950481400669&w=2
There are some subtle differences. The port I sent is in the
category "devel"
instead of "lang". Also, I packaged version 1.0.5 where the local
patch is
already included. DESCR is also slightly different with regards to
formating.

Otherwise both port are equal :)
I changed the DESCR formatting to be different than both of them:
---
WABT (we pronounce it "wabbit") is a suite of tools for WebAssembly,
including:

wat2wasm:
    translate from WebAssembly text format to the WebAssembly binary format

wasm2wat:
    the inverse of wat2wasm, translate from the binary format back to the
    text format (also known as a .wat)

wasm-objdump:
    print information about a wasm binary. Similiar to objdump.

wasm-interp:
    decode and run a WebAssembly binary file using a stack-based
interpreter

wat-desugar:
    parse .wat text form as supported by the spec interpreter
    (s-expressions, flat syntax, or mixed) and print "canonical" flat
format

wasm2c:
    convert a WebAssembly binary file to a C source and header
---

Thanks for your review :)

I attached a new tar which integrates your feedback. Some comments inline ...

It reads better for my eyes but I guess these things eventually become a
matter of opinion.

On the more necessary side of things:
* the build picks up a -Werror that has to go
I patched the CMakeLists.txt. Is there a better way to this?

* CMake will pick up re2c if you have it installed so either set
-DRUN_RE2C=OFF in CONFIGURE_ARGS or add a BDEP on re2c.
Added the BDEP because the option is on by default.
re2c is only needed when you make changes to the lexer, I would prefer
not to make this a build dependency.

Hi.

Yes, you're right. Attached is a new tarball which uses the included lexer
by adding -DRUN_RE2C=OFF and removed the BUILD_DEPENDS.

A few more things, then I think it's ok for import.
* Bonus newline at the end of pkg/DESCR
* Usually I see COMPILER=base-clang ports-gcc but I don't know how much that matters nowadays * Judging by the CMakeLists.txt, python is only used running the tests, since we are using the prebuilt stuff. So maybe better is to remove the find_package for Python from CMakeLists.txt and then we can get rid of the python MODULE.

~Brian

Thanks,
Fabian

* It's C++11, so needs a COMPILER line.
Done.

* It looks for, and finds, python. Do we need to add MODULES=lang/python?

There's no MAINTAINER. Either of you want to do it?
I would take it and added myself as MAINTAINER if that's ok for Raphael
sure..

And now that I think about it, I think I like this living in lang/. devel/
is overloaded, and we can at least justify this one living somewhere else.
Done.

~Brian

~Brian

I'm still waiting for an OK to import that one.

~Brian

Reply via email to