I ask a question about CVS/SVN hosting on sr.ht, and I am recommended to
check into my local psychiatric ward. I just prefer Subversion over Git,
and sending me the same Linus talk you always see in discussions about
centralized versioning does not change that fact.

I guess I could try hacking git.sr.ht to use Subversion, but that does
not sound like a fun first web development project. Even if I did, and
it miraculously worked, it probably wouldn't get enough use to justify
hosting it, I guess.

Are there any plans or intentions to add centralized versioning to
SourceHut, like CVS or SVN?

This patch adds functionality to QBE that allows
specifying the visibility of a function, similar
to GCC's __attribute__((visible)) or MSVC's
__declspec(dllexport).

---
 all.h      |  1 +
 doc/il.txt |  5 +++++
 emit.c     |  7 +++++++
 parse.c    | 13 ++++++++++---
 4 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/all.h b/all.h
index bb6f096..769552e 100644
[message trimmed]

Actually, looking through the manual, I can't find anything for any target
regarding exporting symbols in the final binary. There is the option that
adding the function to the .drectve be a job for the language frontend,
but this feels like something QBE should handle. I don't want to make a
language design decision, so I won't try and implement it. You should bring
this up outside of this thread in the mailing list and see what Quentin has
to say.

> People still are using it, and here's one relatively recent discussion of relevance, where particularly the lab equipment argument is one that often gets overlooked:

I can understand if people can't upgrade, but I don't think that a modern peice
of software should be required to accomodate for them. It is fine if you want
to implement it, I just don't think it would be worth it.

> Windows could mean in this context either win32 (utf-16) or midipix (int); and even without the midipix target, to properly implement L' literals from within QBE you'd need to make the size of wchar_t a target-specific property.

This should be a job for the language front-end, not QBE.

> Perhaps I'm missing something, however dllimport is not the same thing as extern, and grepping QBE for __imp_ suggests that nothing currently handles it.

From what I can tell, the only thing dllexport/dllimport does is mangle the
name. Doing so probably isn't worth adding a new keyword for. You couldn't make

The naming is pretty messy; I just wrote the first thing that came to mind.
I want to keep the target name short, though. amd64_windows is a bit too
long in my opinion. amd64_win32 is a bit misleading, as it makes you wonder
if it really is 64-bit or not. I also feel like calling the "midipix" target
"winnt" is REALLY misleading.

32-bit support doesn't seem to be a priority. I for one think it should die
already.

wchar_t differing in width seems beyond the scope of QBE. Certain targets
using different sizes is a confusing thing that I do not think is a good
idea. (Also, I thought Windows only used UTF-16 for wchar_t?)

How would dllimport/dllexport be any different from already existing

> Would it be possible to set up a GitHub action for this?
https://github.com/msys2/setup-msys2 appears to be the official way of
using CI with MSYS2. Once it is set up, the same ./configure; make;
should work fine.

This patch enables the use of QBE's experimental winabi target. This
target is found on the winabi branch of QBE, at c9x.me/git/qbe.git.
---
 configure | 4 ++++
 driver.c  | 9 +++++++--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index fe5688a..e7e5860 100755
--- a/configure
+++ b/configure
@@ -122,6 +122,10 @@ case "$target" in
 	endfiles='"-l", "c", "-l", ":crtn.o"'
 	defines='"-D", "__builtin_stdarg_start(ap, last)=__builtin_va_start(ap, last)"'
[message trimmed]