Should util/quickstart/setchplenv.bash use system LLVM when available?

[mppf]

Now that we are building the LLVM support library when CHPL_LLVM=none, I am finding that a quicker quickstart, for me personally, would set CHPL_LLVM=system. However if LLVM isn't installed, that's definitely not the right setting for quickstart. But util/quickstart/setchplenv.bash could run some of our chplenv Python code in order to determine if a system LLVM would be used and in that case leave CHPL_LLVM=system.

Is that a good idea? Would we want to do it for other libraries?

Another way to think about this question is this: which is more important about quickstart - that it is quick? or that it is a consistent configuration across systems?

[mppf]

I suppose another possibility would be to add a sibling to util/quickstart with some other name that means "system libraries if available" or something like that.

[bradcray]

To clarify, how does having CHPL_LLVM=none set increase build-time when a system LLVM is installed? Does it necessarily build the bundled LLVM support library rather than using the system support libraries if they're available? Could that logic simply be updated to use the system LLVM support library if it's available? After all, the user didn't request bundled per se, so what would make us prefer it?

[Related: should the user have a separate variable that says where to get the support libraries from given that it seems a little weird to say "LLVM=none" and then have the makefiles say "OK, I won't use LLVM [but will use your system|bundled support libraries without you being any the wiser]."

[mppf]

To clarify, how does having CHPL_LLVM=none set increase build-time when a system LLVM is installed? Does it necessarily build the bundled LLVM support library rather than using the system support libraries if they're available?

Yes, currently.

Could that logic simply be updated to use the system LLVM support library if it's available?

Perhaps, but at least today, CHPL_LLVM=none means "use the bundled support library". Our Makefiles would have to consider two cases; CHPL_LLVM=none but we're using a system support library and CHPL_LLVM=none but we are using the bundled support library. In other words, it would probably be necessary to have another variable within the Makefiles.

After all, the user didn't request bundled per se, so what would make us prefer it?

That seems like a pretty good argument.

[Related: should the user have a separate variable that says where to get the support libraries from given that it seems a little weird to say "LLVM=none" and then have the makefiles say "OK, I won't use LLVM [but will use your system|bundled support libraries without you being any the wiser]."

Yes if we wanted to try to expose these details to the user, we could have e.g. CHPL_LLVM_SUPPORT that could be bundled or system. We could choose a default for CHPL_LLVM_SUPPORT independently from CHPL_LLVM or its setting.

[bradcray]

Thanks for confirming. To me, the approach we're sketching in the comment just above seems "obviously attractive" (by making things more explicit) and preferable to simply inferring CHPL_LLVM=system for the quickstart as a means of addressing the build-time issue in the OP.

That said, it also raises the more general question that hadn't occurred to me, taking build-time out of the equation: Since defaulting to the system LLVM doesn't really increase build-time relative to the C back-end, and could also arguably improve the user experience by not bringing differences between back-end C compilers into the equation, would it make sense to have quickstart default to CHPL_LLVM=system when available by the argument of "nothing lost, something potentially gained" (again, ignoring the build-time issues in the OP here). I think the reservations I have about that are:

• I'm not particularly clear on how solid our system LLVM detection is. I feel like some user experiences have been along the lines of "Well, I've got LLVM installed, but not all the llvm/clang dev packages, so it didn't use my system LLVM" and I'm not sure whether we'll run into more of those kinds of portability issues if more users are trying LLVM as part of quickstart. Meanwhile, we have a lot of experience using the C back-end by default and it hasn't really caused obvious problems that I'm aware of. Obviously, I think we'd like to make LLVM detection airtight, and this would be a way to get more pressure on it, but I know these LLVM portability issues aren't anyone's favorite thing to work on.
• The point you raise about consistency vs. inconsistency of quickstart configurations across users

The second gave me pause initially, but maybe inappropriately: After all, when users have problems, I don't think we often say "Oh, you're not using this precise quickstart configuration, so please do make these changes." We just help them with their bugs. And also, we're arguably better at debugging configurations that are more like the preferred configuration than the quickstart configuration...

[mppf]

I've made an initial attempt at addressing this in PR #20396.

[mppf]

Closing this issue because PR #20396 addressed it.

[e-kayrakli]

This is potentially a tangent to what's discussed here, but should we change something in our test system as quickstart and gasnet.quickstart configs use CHPL_LLVM=none today?

Probably, that's because we don't source the LLVM setup script before they run. But I feel like given the direction here, we should make these settings use system LLVM, too. I suspect that's the more common "quickstart" environment going forward.

Edit: I wrote this comment, but then opened https://github.com/Cray/chapel-private/issues/4221 for it.