Get rid of 'require "-l<lib>"'

[BryantLam]

Discussion/feature request dequest. Get rid of require "-lfoo" support for specifying link flags in source files. Or at least get rid of it on non-internal packages.

Currently used in these packages (egrep 'require.*-l' -R $CHPL_HOME/modules):

• internal/localeModels/knl/LocaleModel.chpl
• packages/HDFS.chpl
• packages/FFTW_MT.chpl (oddly, not FFTW.chpl)
• packages/NetCDF.chpl
• packages/ZMQ.chpl

Why?

• The linker is already magic to most people. This creates more implicit magic that is hard to debug. Recently, I tried to use the ZMQ module and it had require "-lzmq" in its source module file and, not knowing that, wasted a ton of time doubting my knowledge of linkers.
• It's used inconsistently. Two packages--BLAS and LinearAlgebra--point out in their documentation that the user already has to specify library link flags manually due to choices that are available.
• It stifles alternatives.
• If Chapel packages are installed on a system and cannot be source-modified by its users, how can a user bypass this requirement?

[bradcray]

Naive question: Would converting these libraries to mason packages provide a better way of specifying the link-time flags in a flexible manner without requiring the user to manually add them to a compilation command-line?

[BryantLam]

My opinion is that if the user is using these packages from the command line (i.e., without Mason), they have to manage the link options themselves. But if the application was being built through/by Mason, then sure, the link options could be specified in that application's Mason.toml file; those link options should not be specified in the Mason.toml file of those packages--otherwise it's really no different than the current status quo. How would a user bypass the link options and specify their own if a package had link options specified in a Mason.toml file that was at system-level? One option is a precedence order (to always prefer the link options as written by a user), but I don't know if that gets complicated with tree dependencies.

I'm open to ideas for handling link options through Mason, but definitely not in the source code. There needs to be a way to opt out or supply alternatives to a package's link options (if that is the route taken), especially if the goal is to link in a different implementation of a library interface.

Edit: My opinion has changed since Aug 2019. It's okay to specify the link flags in that package's Mason.toml file and give the user a way to override e.g., in the user's project's Mason.toml file, if they desire an alternative or need to specify other flags or whatever.