Remove usage of the flesh-based library mechanism

[Ian Hinder]

All (most?) flesh-based lirbary mechanisms have been deprecated in favour of ExternalLibraries/*. It is probably a good idea to completely disable the old mechanism since having any mixture of thorns/optionlists using the old and new mechanisms is completely untested and will likely lead to problems and confusion. It's better to give a useful fatal error message if someone still specifies something old in their optionlist than to have things break in other weird and wonderful ways.

Keyword: postrelease

[Frank Löffler]

Make old configuration a warning, not an error

[Ian Hinder]

We discussed this in the call today. I think the reason for keeping any knowledge of these options was that someone might have set the variable in their optionlist for the side effect that it would be set as an environment variable and then used by something else. Now that I think about it, I don't understand this. Can you explain your logic here? What is wrong with just getting rid of all the obsolete code (which doesn't work anyway)?

[Frank Löffler]

The "code" behind this should go. The only question really was whether to give a "pointer" (warning) when a user has one of the old options set. While in principle it would be nice to give this, it can present a problem when someone uses that very same option for something else on their installation, and because some of these names are pretty generic this might actually happen. In such a case, the environment variable X might be necessary for software Y, but would trigger a warning in Cactus. Now - with a warning this might actually not be a problem - only with an error it would. Even the warnings we could/should remove after one or two releases.

[Ian Hinder]

So you are talking about people setting their Cactus options as environment variables in their shell startup files? We really need to fix #332. This should not be allowed. See also #1042.

[Frank Löffler]

No. I am talking about potentially totally unrelated software, installed in the users home, that requires environment variables to be set that might collide with the ones Cactus used to use.

[Ian Hinder]

I think if Cactus is not using an environment variable, it probably shouldn't care about what it is set to (if only the developers of bash could have had the same reasoning...). I propose to just remove all the code. I doubt this will affect anyone.

[Roland Haas]

It's not Cactus itself that uses the environment variable, but make. Ie something like:

FOO=$(HDF5_DIR)

will use the environment variable HDF5_DIR if HDF5 dir was not set in the makefile. See ticket #100 where this already came up and https://www.gnu.org/software/make/manual/html_node/Environment.html for make's behaviour.

[Roland Haas]

The last remaining one was for PTHREADS which is provided in #959 . Note that we should not remove the functionality but rather just no longer use it in the ET (keeping the holy cow alive a bit linger).