Remove usage of the flesh-based library mechanism

Create issue
Issue #980 closed
Ian Hinder created an issue

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

Comments (17)

  1. Ian Hinder reporter
    • removed comment

    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)?

  2. Frank Löffler
    • removed comment

    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.

  3. Ian Hinder reporter
    • removed comment

    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.

  4. Frank Löffler
    • removed comment

    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.

  5. Ian Hinder reporter
    • removed comment

    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.

  6. Roland Haas
    • removed comment

    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).

  7. Log in to comment