- changed milestone to ET_2013_11
- removed comment
Remove usage of the flesh-based library mechanism
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 (16)
-
-
- changed milestone to ET_2014_05
- removed comment
-
- changed milestone to ET_2014_11
- removed comment
-
- changed title to Remove support for the flesh-based library mechanism
- removed comment
-
- removed comment
Make old configuration a warning, not an error
-
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)?
-
- 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.
-
reporter - removed comment
-
- 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.
-
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.
-
repo owner - removed comment
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#100where this already came up and https://www.gnu.org/software/make/manual/html_node/Environment.html for make's behaviour. -
- removed milestone
- removed comment
-
- changed status to open
- assigned issue to
- removed comment
-
repo owner - 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). -
repo owner - changed title to Remove usage of the flesh-based library mechanism
- removed comment
-
repo owner - changed status to resolved
- removed comment
- Log in to comment