Chicago
From Rosie Keith Languet to ~sircmpwn/hare-users
> It's `namebuf` in mkfile (cmd/hare/plan.ha:312) being called from > `sched_hare_object` in cmd/hare/schedule.ha:229 That was it! Thanks everybody :D
From Rosie Keith Languet to ~sircmpwn/hare-users
Hi, I'm trying to build a hare module deeply nested within an existing mixed hare and C project and encountering the following error: `Abort: ./bufio/memstream.ha:65:22: bufio::fixed buffer exceeded` user.ha: │ use targets::socs::allwinner; │ //use targets::socs::allwinne; │ ... └ let number: size = allwinner::test; targets/socs/allwinner/todo.ha: │ export def test: size = 42; └
From Rosie K Languet to ~sircmpwn/hare-dev
--- docs/hare.scd | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/hare.scd b/docs/hare.scd index 1b8196e2..3003951d 100644 --- a/docs/hare.scd +++ b/docs/hare.scd @@ -92,7 +92,8 @@ value, and optional context, separated by tabs. linker flags. Note: use of *-l* currently implies the build tag *libc*. Use *-T -libc* to override this behavior. See *CUSTOMIZING BUILD TAGS*. override this behavior. See *CUSTOMIZING BUILD TAGS*. Furthermore, combining[message trimmed]
From Rosie K Languet to ~sircmpwn/hare-dev
--- docs/hare.scd | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/hare.scd b/docs/hare.scd index ba23eb25..1b8196e2 100644 --- a/docs/hare.scd +++ b/docs/hare.scd @@ -91,6 +91,9 @@ value, and optional context, separated by tabs. *pkg-config --libs* (see *pkg-config*(1)) to obtain the appropriate linker flags. Note: use of *-l* currently implies the build tag *libc*. Use *-T -libc* to override this behavior. See *CUSTOMIZING BUILD TAGS*.[message trimmed]
From Rosie Keith Languet to ~sircmpwn/hare-dev
👍
From Rosie Keith Languet to ~sircmpwn/hare-dev
Lassi: thanks for the thorough response! > the presence of -l flags is used as a heuristic to select which linker > and tags to use. That makes enough sense. This probably fixes more builds than it breaks at this point. > It would probably make sense to add a flag to disable this behavior, > or maybe only enable it when -lc is used Or maybe a notice about this in the man page section for the -l flag? I'm happy to submit a patch for that! Drew: yeah I've steered clear of linking with libc (-lc, -l:libc.a, etc)
From Rosie Keith Languet to ~sircmpwn/hare-dev
Hi, I've encountered some behavior surprising to me while playing around with some basic mixing of hare, C, and cross-compilation. I'm writing to ask for each of these two surprises: 1. Have I done something wrong / missed something in a man page? 2. Does this look like a hare issue, gcc issue, or qbe issue? # Setup I'm on x86_64 Alpine Edge with the master branches of harec, hare, and qbe. The only interesting difference is: I'm using aarch64-none-elf-gcc for cross compiling. I have edited config.mk to reflect this: ```Makefile
From Rosie K Languet to ~autumnull/haredo-devel
--- src/main.ha | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/main.ha b/src/main.ha index ae42c2a..9365d99 100644 --- a/src/main.ha +++ b/src/main.ha @@ -402,8 +402,11 @@ fn find_do_file(target: str) (do_paths | void | errors::overflow) = { }; path::add(&dobuf, "..")!; const pathseg = path::basename(&dobuf); if (pathseg == "/") break; [message trimmed]
From Rosie Keith Languet to ~autumnull/haredo
I spoke too soon here: > A cursory skim over src/main.ha didn't trigger any red-flags for me, > but if you also suspect this to be a bug then I'd love to try and > find+patch it! I think I found it! src/main.ha:415 Is reading and writing from targetbuf at the same time. Patch in progress... -RKL
From Rosie Keith Languet to ~autumnull/haredo
First: Hi, thanks for making haredo! I'm trying out haredo, migrating a Makefile project to haredo and I may have encountered a bug while replicating the segregated build/ layout. https://git.sr.ht/~roselandgoose/kyu Context: I like being able to have the 'clean' task and .gitignore be as simple as `rm -r build/`, so I have my Makefiles live next to their source files but targetting build/$file.c.o for example. Problem: I have a default.do file that is called for a build/$file.o target, but