Re: New package: libgccjit-10.2.1_pre1

[lane-brain <lane-brain@users.noreply.github.com>]

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

New comment by lane-brain on void-packages repository

https://github.com/void-linux/void-packages/pull/28785#issuecomment-1099486960

Comment:
> So, idk exactly how libgccjit works, but should we split off a `-devel` package?

In my reasoning, I didn't opt to do a devel package was because the only use for this package, as far as I can tell, is to be able to build software that one is compiling from source on the host machine for direct use (also implied by its status as a JIT compilation library). It seems different than, for example, a package in which you have a split between the users of software and the distributors who build that software from source. The devel package is used by the latter to produce binaries for the former, while the former doesn't need the devel package to use the software. If we were in a situation where Void was making packages that provided native-comp'd lisp packages for the void-package repo, that would be one thing in favor of splitting them off, because we would then tag those packages with a dependency for the main package only, while putting the devel in [host]makedepends.

One problem that then arises is, I don't know if either package is functional without the other. Look at the package list:

```
🖊  xls libgccjit-devel 
/usr/include/libgccjit++.h
/usr/include/libgccjit.h
/usr/share/info/libgccjit.info.gz
/usr/lib/libgccjit.so -> /usr/lib/libgccjit.so.0


🖊  xls libgccjit      
/usr/lib/libgccjit.so.0.0.1
/usr/share/licenses/libgccjit/RUNTIME.LIBRARY.EXCEPTION
/usr/lib/libgccjit.so.0 -> /usr/lib/libgccjit.so.0.0.1
```

libgcc, for example, includes all the .so files in the main package, and I believe that would be what's required for binary compatibility for Ahead-Of-Time compiled lisp packages in libgccjit's case. But nativecomp would be broken for JIT until the user installed the headers, and given that the package is called "libgccjit", I see it being a source of more confusion than it's worth to split apart the packages, especially when it seems like a hazy issue to decide whether it is in fact more logically consistent to do so.

I'm ready to commit with your changes, but let me know if you want me to do it with the devel package or not, or whether you want me to move the shared object symlink to the main package if we are keeping it.