[PR PATCH] New package: c3c-0.7.0

[PR PATCH] New package: c3c-0.7.0

[hyperpastel]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

There is a new pull request by hyperpastel against master on the void-packages repository

https://github.com/hyperpastel/void-packages c3c
https://github.com/void-linux/void-packages/pull/55087

New package: c3c-0.7.0
#### Testing the changes
- I tested the changes in this PR: **YES**


#### New package
- This new package conforms to the [package requirements](https://github.com/void-linux/void-packages/blob/master/CONTRIBUTING.md#package-requirements): **YES**

#### Local build testing
- I built this PR locally for my native architecture, x86_64-libc



A patch file from https://github.com/void-linux/void-packages/pull/55087.patch is attached

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: github-pr-c3c-55087.patch --]
[-- Type: text/x-diff, Size: 1187 bytes --]

From 1065a5c1cb37abb20a0936999ed2ea99855c5ccb Mon Sep 17 00:00:00 2001
From: hyperpastel <vmutze04@gmail.com>
Date: Wed, 16 Apr 2025 22:23:34 +0200
Subject: [PATCH] New package: c3c-0.7.0

---
 srcpkgs/c3c/template | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)
 create mode 100644 srcpkgs/c3c/template

diff --git a/srcpkgs/c3c/template b/srcpkgs/c3c/template
new file mode 100644
index 00000000000000..d5f2b9d3f9fee7
--- /dev/null
+++ b/srcpkgs/c3c/template
@@ -0,0 +1,21 @@
+# Template file for 'c3c'
+pkgname=c3c
+version=0.7.0
+revision=1
+build_style=cmake
+configure_args="-DCMAKE_BUILD_TYPE=Release"
+hostmakedepends="cmake"
+makedepends="llvm17-devel lld17-devel ncurses-devel zlib-devel libzstd-devel libxml2-devel"
+depends="llvm17"
+short_desc="Compiler for the C3 language"
+maintainer="hyperpastel <vmutze04@gmail.com>"
+license="LGPL-3.0-only AND MIT"
+homepage="https://c3-lang.org/"
+distfiles="https://github.com/c3lang/c3c/archive/refs/tags/v${version}.tar.gz"
+checksum=dc0e507ad4f11df2535e19f73d657c2337f72e017344504429919be3f29bcb71
+
+post_install() {
+	vman		"${wrksrc}/c3c.1"
+	vlicense	"${wrksrc}/LICENSE"
+	vlicense	"${wrksrc}/LICENSE_STDLIB"
+}

Re: [PR REVIEW] New package: c3c-0.7.0

[meator]

[-- Attachment #1: Type: text/plain, Size: 237 bytes --]

New review comment by meator on void-packages repository

https://github.com/void-linux/void-packages/pull/55087#discussion_r2048534147

Comment:
```
build_style=cmake
```

implies `cmake` in `hostmakedepends`:

```suggestion
```

Re: [PR REVIEW] New package: c3c-0.7.0

[meator]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

New review comment by meator on void-packages repository

https://github.com/void-linux/void-packages/pull/55087#discussion_r2048547841

Comment:
`CMAKE_BUILD_TYPE` should not be overridden unless the build system requires it. `xbps-src` heavily overrides the configuration process (it also sets `-DCMAKE_BUILD_TYPE=None` in the `cmake` build style), you should let it do its job.

I have verified that `c3c` builds successfully without this flag. Is there some other reason why this flag is necessary or did you include because https://github.com/c3lang/c3c recommends it?

Re: [PR REVIEW] New package: c3c-0.7.0

[meator]

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

New review comment by meator on void-packages repository

https://github.com/void-linux/void-packages/pull/55087#discussion_r2048532867

Comment:
These `v*` helpers already operate on files relative to `$wrksrc`:

```suggestion
	vman		c3c.1
	vlicense	LICENSE
	vlicense	LICENSE_STDLIB
```

Re: [PR REVIEW] New package: c3c-0.7.0

[hyperpastel]

[-- Attachment #1: Type: text/plain, Size: 336 bytes --]

New review comment by hyperpastel on void-packages repository

https://github.com/void-linux/void-packages/pull/55087#discussion_r2048624674

Comment:
I only included it per suggestion of the GitHub repository, I would not know of any other reason to keep it then if ``xbps-src`` does things itself. I will remove it then :relieved:   

Re: [PR PATCH] [Updated] New package: c3c-0.7.0

[hyperpastel]

[-- Attachment #1: Type: text/plain, Size: 667 bytes --]

There is an updated pull request by hyperpastel against master on the void-packages repository

https://github.com/hyperpastel/void-packages c3c
https://github.com/void-linux/void-packages/pull/55087

New package: c3c-0.7.0
#### Testing the changes
- I tested the changes in this PR: **YES**


#### New package
- This new package conforms to the [package requirements](https://github.com/void-linux/void-packages/blob/master/CONTRIBUTING.md#package-requirements): **YES**

#### Local build testing
- I built this PR locally for my native architecture, x86_64-libc



A patch file from https://github.com/void-linux/void-packages/pull/55087.patch is attached

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: github-pr-c3c-55087.patch --]
[-- Type: text/x-diff, Size: 1079 bytes --]

From ad576007ac4032aae3989418ca2ca2ff884cc373 Mon Sep 17 00:00:00 2001
From: hyperpastel <vmutze04@gmail.com>
Date: Wed, 16 Apr 2025 22:23:34 +0200
Subject: [PATCH] New package: c3c-0.7.0

---
 srcpkgs/c3c/template | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 srcpkgs/c3c/template

diff --git a/srcpkgs/c3c/template b/srcpkgs/c3c/template
new file mode 100644
index 00000000000000..0d3b3bb3abdfd5
--- /dev/null
+++ b/srcpkgs/c3c/template
@@ -0,0 +1,19 @@
+# Template file for 'c3c'
+pkgname=c3c
+version=0.7.0
+revision=1
+build_style=cmake
+makedepends="llvm17-devel lld17-devel ncurses-devel zlib-devel libzstd-devel libxml2-devel"
+depends="llvm17"
+short_desc="Compiler for the C3 language"
+maintainer="hyperpastel <vmutze04@gmail.com>"
+license="LGPL-3.0-only AND MIT"
+homepage="https://c3-lang.org/"
+distfiles="https://github.com/c3lang/c3c/archive/refs/tags/v${version}.tar.gz"
+checksum=dc0e507ad4f11df2535e19f73d657c2337f72e017344504429919be3f29bcb71
+
+post_install() {
+	vman		c3c.1
+	vlicense	LICENSE
+	vlicense	LICENSE_STDLIB
+}

Re: New package: c3c-0.7.0

[hyperpastel]

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

New comment by hyperpastel on void-packages repository

https://github.com/void-linux/void-packages/pull/55087#issuecomment-2812393049

Comment:
I've implemented the changes, thank you so much for your input and feedback :blush: 

I amended locally and then pushed to the remote, was this the right way of doing this, or should I have done something differently with the 'reviewed changes' and 'conversation' sections GitHub showed?  

Re: New package: c3c-0.7.0

[meator]

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]

New comment by meator on void-packages repository

https://github.com/void-linux/void-packages/pull/55087#issuecomment-2812464565

Comment:
If I remember the process correctly, you were given a button to apply the recommended changes I gave you. It is best to ignore this button when contributing to void-packages, because it adds one commit per fix. This violates the ["commit guidelines"](https://github.com/void-linux/void-packages/blob/master/CONTRIBUTING.md#committing-your-changes) of void-packages.


> I amended locally and then pushed to the remote

This is the correct way to deal with feedback in pull requests to void-packages.

Re: New package: c3c-0.7.0

[data-man]

[-- Attachment #1: Type: text/plain, Size: 172 bytes --]

New comment by data-man on void-packages repository

https://github.com/void-linux/void-packages/pull/55087#issuecomment-2812567615

Comment:
Why didn't you choose llvm19?

Re: New package: c3c-0.7.0

[hyperpastel]

[-- Attachment #1: Type: text/plain, Size: 470 bytes --]

New comment by hyperpastel on void-packages repository

https://github.com/void-linux/void-packages/pull/55087#issuecomment-2812630534

Comment:
Ah, I apologise. All the builds of c3c I ever did myself had used llvm17 so I put it here by habit. I will amend once more when I'm home. 
I would assume it would work, but should I test locally again? If so it would take a bit because the laptop I have with me is not running Void (yet).
Or should I leave this to the CI?

Re: New package: c3c-0.7.0

[data-man]

[-- Attachment #1: Type: text/plain, Size: 315 bytes --]

New comment by data-man on void-packages repository

https://github.com/void-linux/void-packages/pull/55087#issuecomment-2812663363

Comment:
> I would assume it would work, but should I test locally again? 
> Or should I leave this to the CI?

I don't know, I'm not a Void user. But I am a former C3 user. 😄

Re: New package: c3c-0.7.0

[hyperpastel]

[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]

New comment by hyperpastel on void-packages repository

https://github.com/void-linux/void-packages/pull/55087#issuecomment-2816932835

Comment:
Apologies for my absence the past two days. I had some time today again and looked into this, and I'm pretty sure this is a defect in the i686 gcc compiler.

This can be fixed with this relatively simple patch file:

```patch
--- a/src/compiler/sema_expr.c
+++ b/src/compiler/sema_expr.c
@@ -5136,7 +5136,7 @@ static inline bool sema_expr_analyse_swizzle(SemaContext *context, Expr *expr, E
 	assert(indexed_type);
 	if (is_lvalue) check = CHECK_VALUE;
 	ASSERT_SPAN(expr, len > 0);
-	int index;
+	int index = swizzle[(int)kw[0]] - 1;
 	bool is_overlapping = false;
 	for (unsigned i = 0; i < len; i++)
 	{
@@ -5145,10 +5145,6 @@ static inline bool sema_expr_analyse_swizzle(SemaContext *context, Expr *expr, E
 		{
 			RETURN_SEMA_ERROR(expr, "The '%c' component is not present in a vector of length %d, did you assume a longer vector?", kw[i], vec_len);
 		}
-		if (i == 0)
-		{
-			index = val;
-		}
 		if ((index ^ val) & 0x10)
 		{
 			RETURN_SEMA_ERROR(expr, "Mixing [xyzw] and [rgba] is not permitted, you will need to select one of them.");

```

Applying this results in compilation without errors. 

Should I include this patch until a better solution is found? (i.e. this gets fixed in a later version of gcc?)

Re: New package: c3c-0.7.0

[hyperpastel]

[-- Attachment #1: Type: text/plain, Size: 1546 bytes --]

New comment by hyperpastel on void-packages repository

https://github.com/void-linux/void-packages/pull/55087#issuecomment-2816932835

Comment:
Apologies for my absence the past two days. I had some time today again and looked into this, and I'm pretty sure this is a defect in the i686 gcc compiler.

This can be fixed with this relatively simple patch file:

```patch
--- a/src/compiler/sema_expr.c
+++ b/src/compiler/sema_expr.c
@@ -5136,7 +5136,7 @@ static inline bool sema_expr_analyse_swizzle(SemaContext *context, Expr *expr, E
 	assert(indexed_type);
 	if (is_lvalue) check = CHECK_VALUE;
 	ASSERT_SPAN(expr, len > 0);
-	int index;
+	int index = swizzle[(int)kw[0]] - 1;
 	bool is_overlapping = false;
 	for (unsigned i = 0; i < len; i++)
 	{
@@ -5145,10 +5145,6 @@ static inline bool sema_expr_analyse_swizzle(SemaContext *context, Expr *expr, E
 		{
 			RETURN_SEMA_ERROR(expr, "The '%c' component is not present in a vector of length %d, did you assume a longer vector?", kw[i], vec_len);
 		}
-		if (i == 0)
-		{
-			index = val;
-		}
 		if ((index ^ val) & 0x10)
 		{
 			RETURN_SEMA_ERROR(expr, "Mixing [xyzw] and [rgba] is not permitted, you will need to select one of them.");

```

Applying this results in compilation without errors. 

Should I include this patch until a better solution is found? (i.e. this gets fixed in a later version of gcc?)

I will also look into using LLVM19, just changing the ``*depends`` didn't work and introduced some problems with cmake not finding LLVM anymore

Re: New package: c3c-0.7.0

[meator]

[-- Attachment #1: Type: text/plain, Size: 2800 bytes --]

New comment by meator on void-packages repository

https://github.com/void-linux/void-packages/pull/55087#issuecomment-2817007124

Comment:
> I'm pretty sure this is a defect in the i686 gcc compiler

You're pretty quick to jump to conclusions. The compiler _can_ have bugs, but they shouldn't be the first thing you think of when the compilation process fails.

The problem is caused by upstream using `-Werror`. Using `-Werror` in released software is pretty much always wrong. Upstream maintainers cannot anticipate all the compilers and build environments in which their project will be built. What compiled without warnings on their system may not compile without warnings in the future or on a different system. Package maintainers are usually the ones who pay for this ill-advised solution.

The reported warning seems to be harmless. It could be ignored if it didn't cause a compilation error.

Some googling showed me https://github.com/c3lang/c3c/issues/1907

Possible solutions:
1. Apply the patch you made

   Please make sure that it doesn't change the code's behavior in any way. Bugs introduced by the software distributor are _really hard to debug_. I wouldn't choose this solution because of this.
2. Remove `-Werror`

   This would mean patching/vseding out `-Werror` in https://github.com/c3lang/c3c/blob/v0.7.0/CMakeLists.txt#L530

   As I said earlier, `-Werror` usage here is invalid. This will not only solve the i686 build error of 0.7.0, but it could also solve any other similar errors introduced by future updates.
3. Apply patches from https://github.com/c3lang/c3c/issues/1907

   I would prefer applying patches from this issue rather than your own because the patches and solutions discussed in this issue were acknowledged by an upstream maintainer.

   Some comments in that issue imply that the issue has already been fixed in c3c's master branch and that it will be fixed in the next release. Extracting the commits which solve this issue from `master` and patching them in here is also a good solution. These patches can be dropped once c3c gets updated. These patches have the highest credibility, because they were created by upstream maintainers and are about to be included in the next release (but they are currently in the master branch which is in development, the upstream maintainers may choose to modify the solution before release).

If you want to be nice, you can also notify upstream of these issues:
1. Ask them whether they would be willing to reconsider adding `-Werror` during compilation

   As a package maintainer, I view this as a software bug worth fixing.
2. Maybe comment on https://github.com/c3lang/c3c/issues/1907 to let upstream maintainers know that several distros (not only Gentoo) are affected by this

Re: New package: c3c-0.7.0

[meator]

[-- Attachment #1: Type: text/plain, Size: 703 bytes --]

New comment by meator on void-packages repository

https://github.com/void-linux/void-packages/pull/55087#issuecomment-2817014093

Comment:
> I will also look into using LLVM19, just changing the `*depends` didn't work and introduced some problems with cmake not finding LLVM anymore

The error can be solved with

```
configure_args="-DLLVM_DIR=$XBPS_CROSS_BASE/lib/llvm/19/lib/cmake/llvm/"
```

It is strange though. There is not a single mention of llvm19 in the [README](https://github.com/c3lang/c3c/blob/master/README.md) nor are there any [issues](https://github.com/c3lang/c3c/issues?q=is%3Aissue%20llvm19%20). Maybe upstream doesn't support llvm19 as well as it does llvm18 and llvm17?

Re: New package: c3c-0.7.0

[hyperpastel]

[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]

New comment by hyperpastel on void-packages repository

https://github.com/void-linux/void-packages/pull/55087#issuecomment-2817067548

Comment:
Thank you for your fast and detailed response yet again, meator :smiling_face_with_three_hearts: 

I apologize if my judgement is too quick. It just struck me as something weird that the same few lines of code compile without a warning on all other platforms, and only on i686, a warning is generated (which, unless I'm reading something very wrong, should not be).

I have brought this to the attention of the maintainer, and I will also mention the ``-Werror`` flag.

As for the solutions, I then agree that removing this flag is probably the best. 

I've read the issue you've linked, but I believe this addresses different files, namely ``src/utils/file_utils.c``, ``src/compiler/sema_const.c`` and ``src/compiler/sema_stmts.c``, whereas our culprit resides in ``src/compiler/sema_expr.c`` and is still present in both the [dev](https://github.com/c3lang/c3c/blob/7645999b5f5009f0157dbb76f682e77bbe22c626/src/compiler/sema_expr.c#L4996) and [master](https://github.com/c3lang/c3c/blob/42e4370994a57669819d01dc11dbc9a8ac9a1e7f/src/compiler/sema_expr.c#L5139) branch :melting_face: 

I will wait a bit for a direct response from maintainers, if nothing emerges from that, I would probably go down the ``vsed`` route :blush: 

Re: New package: c3c-0.7.0

[hyperpastel]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

New comment by hyperpastel on void-packages repository

https://github.com/void-linux/void-packages/pull/55087#issuecomment-2817071292

Comment:
As for the ``llvm19`` situation, there is indeed no mention, and this was also the cause why I always built it with ``llvm17`` and then also habitually used ``llvm17`` in the template.

I did ask if there was downsides to using ``llvm19`` over ``llvm17`` when building from source, which I was told there aren't. Probably this is more about the actual software behavior though rather than the CMake behavior :stuck_out_tongue: 

I could always try to test the software's behavior if linked with llvm19, but should we include ``configure_args`` like that in the template? Or would it not better to wait until this is perhaps more popular, mentioned in upstream and has a cleaner solution? :thinking: 

Re: New package: c3c-0.7.0

[meator]

[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

New comment by meator on void-packages repository

https://github.com/void-linux/void-packages/pull/55087#issuecomment-2817100605

Comment:
> I've read the issue you've linked, but I believe this addresses different files, namely `src/utils/file_utils.c`, `src/compiler/sema_const.c` and `src/compiler/sema_stmts.c`, whereas our culprit resides in `src/compiler/sema_expr.c` and is still present in both the [dev](https://github.com/c3lang/c3c/blob/7645999b5f5009f0157dbb76f682e77bbe22c626/src/compiler/sema_expr.c#L4996) and [master](https://github.com/c3lang/c3c/blob/42e4370994a57669819d01dc11dbc9a8ac9a1e7f/src/compiler/sema_expr.c#L5139) branch

Ah, didn't notice that. This showcases that such issues are common in c3c and that removing `-Werror` might be beneficial.

> I did ask if there was downsides to using `llvm19` over `llvm17` when building from source, which I was told there aren't. Probably this is more about the actual software behavior though rather than the CMake behavior

If you've got confirmation from upstream that no issues will arise from using `llvm19`, you should use it.

Re: New package: c3c-0.7.0

[meator]

[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]

New comment by meator on void-packages repository

https://github.com/void-linux/void-packages/pull/55087#issuecomment-2817100605

Comment:
> I've read the issue you've linked, but I believe this addresses different files, namely `src/utils/file_utils.c`, `src/compiler/sema_const.c` and `src/compiler/sema_stmts.c`, whereas our culprit resides in `src/compiler/sema_expr.c` and is still present in both the [dev](https://github.com/c3lang/c3c/blob/7645999b5f5009f0157dbb76f682e77bbe22c626/src/compiler/sema_expr.c#L4996) and [master](https://github.com/c3lang/c3c/blob/42e4370994a57669819d01dc11dbc9a8ac9a1e7f/src/compiler/sema_expr.c#L5139) branch

Ah, didn't notice that. This showcases that such issues are common in c3c and that removing `-Werror` might be beneficial.

> I did ask if there was downsides to using `llvm19` over `llvm17` when building from source, which I was told there aren't. Probably this is more about the actual software behavior though rather than the CMake behavior

If you've got confirmation that no issues will arise from using `llvm19`, you should use it.

Re: [PR PATCH] [Updated] New package: c3c-0.7.0

[hyperpastel]

[-- Attachment #1: Type: text/plain, Size: 667 bytes --]

There is an updated pull request by hyperpastel against master on the void-packages repository

https://github.com/hyperpastel/void-packages c3c
https://github.com/void-linux/void-packages/pull/55087

New package: c3c-0.7.0
#### Testing the changes
- I tested the changes in this PR: **YES**


#### New package
- This new package conforms to the [package requirements](https://github.com/void-linux/void-packages/blob/master/CONTRIBUTING.md#package-requirements): **YES**

#### Local build testing
- I built this PR locally for my native architecture, x86_64-libc



A patch file from https://github.com/void-linux/void-packages/pull/55087.patch is attached

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: github-pr-c3c-55087.patch --]
[-- Type: text/x-diff, Size: 1995 bytes --]

From 58e1579697a090d68847d03e4575b9cc9699821d Mon Sep 17 00:00:00 2001
From: hyperpastel <vmutze04@gmail.com>
Date: Mon, 21 Apr 2025 00:05:24 +0200
Subject: [PATCH] New package: c3c-0.7.0

---
 .../c3c/patches/i686-uninitialized-fix.patch  | 11 ++++++++++
 srcpkgs/c3c/template                          | 21 +++++++++++++++++++
 2 files changed, 32 insertions(+)
 create mode 100644 srcpkgs/c3c/patches/i686-uninitialized-fix.patch
 create mode 100644 srcpkgs/c3c/template

diff --git a/srcpkgs/c3c/patches/i686-uninitialized-fix.patch b/srcpkgs/c3c/patches/i686-uninitialized-fix.patch
new file mode 100644
index 00000000000000..0a207dbced9301
--- /dev/null
+++ b/srcpkgs/c3c/patches/i686-uninitialized-fix.patch
@@ -0,0 +1,11 @@
+--- a/src/compiler/sema_expr.c
++++ b/src/compiler/sema_expr.c
+@@ -5136,7 +5136,7 @@ static inline bool sema_expr_analyse_swizzle(SemaContext *context, Expr *expr, E
+ 	assert(indexed_type);
+ 	if (is_lvalue) check = CHECK_VALUE;
+ 	ASSERT_SPAN(expr, len > 0);
+-	int index;
++	int index = 0;
+ 	bool is_overlapping = false;
+ 	for (unsigned i = 0; i < len; i++)
+ 	{
diff --git a/srcpkgs/c3c/template b/srcpkgs/c3c/template
new file mode 100644
index 00000000000000..d3a07a5dcaadcc
--- /dev/null
+++ b/srcpkgs/c3c/template
@@ -0,0 +1,21 @@
+# Template file for 'c3c'
+pkgname=c3c
+version=0.7.0
+revision=1
+build_style=cmake
+_llvmver=19
+configure_args="-DCMAKE_PREFIX_PATH=$XBPS_CROSS_BASE/lib/llvm/${_llvmver};$XBPS_CROSS_BASE/usr/lib/"
+makedepends="llvm${_llvmver}-devel lld${_llvmver}-devel ncurses-devel libzstd-devel libxml2-devel"
+depends="llvm${_llvmver}"
+short_desc="Compiler for the C3 language"
+maintainer="hyperpastel <vmutze04@gmail.com>"
+license="LGPL-3.0-only AND MIT"
+homepage="https://c3-lang.org/"
+distfiles="https://github.com/c3lang/c3c/archive/refs/tags/v${version}.tar.gz"
+checksum=dc0e507ad4f11df2535e19f73d657c2337f72e017344504429919be3f29bcb71
+
+post_install() {
+	vman		c3c.1
+	vlicense	LICENSE
+	vlicense	LICENSE_STDLIB
+}

Re: New package: c3c-0.7.0

[hyperpastel]

[-- Attachment #1: Type: text/plain, Size: 1629 bytes --]

New comment by hyperpastel on void-packages repository

https://github.com/void-linux/void-packages/pull/55087#issuecomment-2817366942

Comment:
> I would prefer applying patches from this issue rather than your own because the patches and solutions discussed in this issue were acknowledged by an upstream maintainer.

I discussed this with the upstream and [this PR](https://github.com/c3lang/c3c/pull/2102) ended getting merged, so I would patch accordingly with the confirmation of the maintainer. They would like to keep ``-Werror``.

I've spent a bit more time looking into using llvm19. After setting ``-DLLVM_DIR`` like you suggested, I was able to build with it, except for my now favorite architecture ``i686`` :melting_face: 

 I failed with the following error:
```
ninja: error: '/usr/lib/libz3.so', needed by 'c3c', missing and no known rule to make it
```

I don't know if the following is possible, but - I believe that setting ``LLVM_DIR`` like this messed with the inner CMake which provides LLVM, which caused it to not properly find ``libz3.so`` on the ``i686`` architecture. 

So I thought to add both the path you provided earlier (which I was also able to shorten a bit, CMake still finds it without the last parts!) and the "normal" ``$XBPS_CROSS_BASE/usr/lib/`` path, so that LLVM may properly find ``libz3.so``. 

However, ``LLVM_DIR`` appears to only expect one value, so I instead chose to set both paths in ``DCMAKE_PREFIX_PATH`` instead and now it works perfectly!

I also took the liberty to add a variable for the version of the ``llvm``-packages that ``c3c`` depends on :blush: 

Re: New package: c3c-0.7.0

[hyperpastel]

[-- Attachment #1: Type: text/plain, Size: 1635 bytes --]

New comment by hyperpastel on void-packages repository

https://github.com/void-linux/void-packages/pull/55087#issuecomment-2817366942

Comment:
> I would prefer applying patches from this issue rather than your own because the patches and solutions discussed in this issue were acknowledged by an upstream maintainer.

I discussed this with the upstream and [this PR](https://github.com/c3lang/c3c/pull/2102) ended getting merged, so I would patch accordingly with the confirmation of the maintainer. They would like to keep ``-Werror``.

I've spent a bit more time looking into using llvm19. After setting ``-DLLVM_DIR`` like you suggested, I was able to build with it, except for my now favorite architecture ``i686`` :melting_face: 

 I failed with the following error:
```
ninja: error: '/usr/lib/libz3.so', needed by 'c3c', missing and no known rule to make it
```

I don't know if the following is possible, but - I believe that setting ``LLVM_DIR`` like this messed with the inner CMake which provides LLVM, which caused it to not properly find ``libz3.so`` on the ``i686`` architecture. 

So I thought to add both the path you provided earlier (which I was also able to shorten a bit, CMake still finds it without the last parts!) and the "normal" ``$XBPS_CROSS_BASE/usr/lib/`` path, so that LLVM may properly find ``libz3.so``. 

However, I was unable to set ``-DLLVM_DIR`` with both these values in ``configure_args``, so I set it in ``-DCMAKE_PREFIX_PATH`` instead and it works with this!

I also took the liberty to add a variable for the version of the ``llvm``-packages that ``c3c`` depends on :blush: 

Re: New package: c3c-0.7.0

[hyperpastel]

[-- Attachment #1: Type: text/plain, Size: 310 bytes --]

New comment by hyperpastel on void-packages repository

https://github.com/void-linux/void-packages/pull/55087#issuecomment-2823815445

Comment:
https://github.com/c3lang/c3c/pull/2103 has been merged, so in the next release both the extra ``configure_args`` and the patch will no longer be needed :relieved: 

Re: [PR PATCH] [Closed]: New package: c3c-0.7.0

[hyperpastel]

[-- Attachment #1: Type: text/plain, Size: 507 bytes --]

There's a closed pull request on the void-packages repository

New package: c3c-0.7.0
https://github.com/void-linux/void-packages/pull/55087

Description:
#### Testing the changes
- I tested the changes in this PR: **YES**


#### New package
- This new package conforms to the [package requirements](https://github.com/void-linux/void-packages/blob/master/CONTRIBUTING.md#package-requirements): **YES**

#### Local build testing
- I built this PR locally for my native architecture, x86_64-libc