When is setting CHPL_LIB_PIC necessary for working build?

Generalized package formats like flatpaks could also be nice, since we could hit all the distros at once.

Agreed

I don't have any experience in this, but I could look into making one at some point in the future.

That would be super, if you are up for it. Please try to keep us in the loop (e.g. with PRs to util/packaging with what you are planning). But for now let's see if we can get this AUR package into good shape.

I've done all of the make clean s and clobbers, but it doesn't appear there is an uninstall. I deleted the binary in /usr/local/bin manually, but it seems there's more.

Yes you should be able to delete /usr/bin/chpl and /usr/lib/chapel /usr/share/chapel.

We haven't created 'make uninstall' yet but have an open issue asking for it make uninstall · Issue #6353 · chapel-lang/chapel · GitHub if you want to comment there / thumbs up / etc.

Does yay have an uninstall feature that people would expect to work but that needs to be wired up to a make uninstall ? My limited experience with other packaging system is that they have their own way of tracking what files are installed by a package (and so they know which files to remove). And yay -R chapel seemed to remove it for me. I suppose you were just asking about removing a manual install, then.

sudo pacman -S yay; yay -S chapel

I get

# pacman -S yay
error: target not found: yay

But, I found some instructions in GitHub - Jguer/yay: Yet another Yogurt - An AUR Helper written in Go . I was confused by the questions yay then asked me but I just answered 'n', hope that is reasonable.

Anyway, the default configuration Chapel seems reasonable for the AUR package. You can actually build for multiple configurations and then install. On Homebrew, we build for the C backend with GCC as well as with LLVM, so that this can be toggled without having to build from source. So perhaps it should just match that. To do so, you would just CHPL_TARGET_COMPILER=gnu make as well before installing. You could also do a quickstart build (but if you do that, make sure to do an LLVM build afterwards). Depends on how many variations you want the AUR package to support vs. asking people doing something non-default to build from source.

Also it looks like the yay -S chapel does not lead to a parallel build. Not sure it would help much in my VM but it might be nice to make -j4 or something. I have no idea what is typical here for AUR packages. But at least we didn't have to build LLVM :slight_smile:

As for working the Arch packaging into the chapel repo in a PR, I plan to look at that tomorrow.

Great. I think it's likely we'll have more intelligent feedback with that.

undefined reference to chpl_hwloc_get_obj_by_depth'
error: Make Binary - Linking
I am hoping this is caused by my own source builds of Chapel interfering with the new AUR build

No such luck - I see the same problem. One possibility is that your AUR package isn't installing something that is important. Another possibility is that it's a problem with make install. Our configure script actually supports two modes - storing all the Chapel stuff in one directory (--chpl-home) or splitting it among bin lib share directories (--prefix). The Homebrew formula uses the all-in-one directory and that might get you to something working sooner. But if there is a problem with make install with the other strategy we should fix it.

I did my own experiment on my Arch VM with a --prefix install. Worked OK for quickstart and default builds. So I think it's more likely that the AUR scripting is missing something that should be installed or there is some other problem with it. If you make it into a PR then I can review it & see if I see anything obviously wrong (where I'm more familiar with the Chapel end than the AUR end, obviously).

Actually I'm not so sure if snap/flatpak can work for Chapel because, while we could make the compiler available as a snap/flatpak, how would the binaries built with chpl link to the runtime? Would they have to point to something inside of the snap/flatpak image? Seems like something that model would not support, but I don't know.

My understanding is also "no", it takes care of this by tracking files.

etc/makepkg.conf has a configuration variable to set make flags across all package builds, where the user can put their preferred -j ??

I have zero experience with flatpak's besides installing and using them very infrequently, but I believe each package includes all the necessary runtime, with the possibility of sharing runtimes between apps. This leads to very simple (but possibly large) installs.

Darn. I'll just make a PR of the current broken version so we can collaborate and discuss more easily, then I'll do some trial and error with configure directory structures to try to get it working. Thanks for doing that --prefix test.