Automatic package reconfiguration and ConfigExFlags

Hello! Today I merged commits for automatic reconfiguration and rebuilding of a package as necessary when 'cabal test' and 'cabal bench' are invoked. The automatic reconfiguration code is based on the code already used to reconfigure packages when './Setup build' and 'cabal build' are invoked. I noticed that the existing reconfiguration code does not account for ConfigExFlags that may have been passed to 'cabal configure' the last time the package was configured. (My alterations do not affect this behaviour.) The purpose of this message is to bring attention to the problems I think this could cause and with the help of the community, determine the actual severity of the issue. Then we can decide if/when and how to resolve it. Obviously, if Cabal is being invoked through a 'Setup' script, there is no need for concern. However, ConfigExFlags affect dependency resolution during configuration, so automatic reconfiguration that ignores them may silently and unexpectedly change how the package is linked. I'm concerned this could (hypothetically) lead to linking to a different version of a dependency, causing build failure (or worse, if different versions of the dependency have different behaviours). I also have some reason to believe the situation is not that dire. After the initial configuration, the resolved dependencies are saved in the ConfigFlags in the LocalBuildInfo. When reconfiguring, the worst possible outcome should be that the dependency resolver cannot resolve the given dependencies and versions without some ConfigExFlags that would now be missing. To get my patches merged, I ignored this issue. The easiest solution is simply to include the ConfigExFlags in the LocalBuildInfo. That is something that could be done when/if the 'Setup' script builds actually become deprecated, since the ConfigExFlags reside in cabal-install, but the LocalBuildInfo is in Cabal. We may want to take care of this in the short term, but on the other hand, it could probably wait: this is far from a new issue, and I can't document any case of someone actually bitten by this bug. Feel free to tell me I'm making this out to be more than it is, but I thought I should present it before the community. Thanks! -- Thomas Tuegel

Hi,
On Tue, Aug 14, 2012 at 12:29 AM, Thomas Tuegel
ConfigExFlags affect dependency resolution during configuration, so automatic reconfiguration that ignores them may silently and unexpectedly change how the package is linked. I'm concerned this could (hypothetically) lead to linking to a different version of a dependency, causing build failure (or worse, if different versions of the dependency have different behaviours).
The obvious solution is to save ConfigureExFlags between runs, just like is done with LocalBuildInfo, but in a separate, cabal-install specific, file (e.g., dist/cabal-install-setup-config). From a brief glance at the code, this requires changing only 'reconfigure' in cabal-install/Main.hs. Are there reasons to prefer merging ConfigExFlags with ConfigFlags instead? -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

On Thu, Aug 16, 2012 at 9:19 PM, Mikhail Glushenkov
Hi,
On Tue, Aug 14, 2012 at 12:29 AM, Thomas Tuegel
wrote: ConfigExFlags affect dependency resolution during configuration, so automatic reconfiguration that ignores them may silently and unexpectedly change how the package is linked. I'm concerned this could (hypothetically) lead to linking to a different version of a dependency, causing build failure (or worse, if different versions of the dependency have different behaviours).
The obvious solution is to save ConfigureExFlags between runs, just like is done with LocalBuildInfo, but in a separate, cabal-install specific, file (e.g., dist/cabal-install-setup-config). From a brief glance at the code, this requires changing only 'reconfigure' in cabal-install/Main.hs. Are there reasons to prefer merging ConfigExFlags with ConfigFlags instead?
You will need to change 'reconfigure' to load and reuse the ConfigExFlags, but you would also need to change 'configureAction' to save them in the first place. There's no particular reason _not_ to save the ConfigExFlags in a separate file, except this: At one time (and this may still be true, I'm not the authority on this) there was a plan to move all the Simple build system stuff out of Cabal and into cabal-install, at which time the ConfigFlags and ConfigExFlags would presumably be merged, solving the problem "for free," essentially. If this is no longer the plan, or if the desired time frame for fixing this bug is shorter than this plan's time-to-completion, then we should probably do as you suggest. -- Thomas Tuegel

Hi,
On Fri, Aug 17, 2012 at 4:32 AM, Thomas Tuegel
There's no particular reason _not_ to save the ConfigExFlags in a separate file, except this: At one time (and this may still be true, I'm not the authority on this) there was a plan to move all the Simple build system stuff out of Cabal and into cabal-install, at which time the ConfigFlags and ConfigExFlags would presumably be merged, solving the problem "for free," essentially.
Thanks for the clarification.
If this is no longer the plan, or if the desired time frame for fixing this bug is shorter than this plan's time-to-completion, then we should probably do as you suggest.
I'm not the authority on this either :) We should wait for Duncan or Andres to weigh in. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

On Thu, Aug 16, 2012 at 7:32 PM, Thomas Tuegel
If this is no longer the plan, or if the desired time frame for fixing this bug is shorter than this plan's time-to-completion, then we should probably do as you suggest.
Since no one is working on it and people are quite busy my guess is that this refactoring isn't going to happen soon and in that case I'd be in favor of having the ConfigExFlags written to a separate time in the mean time. If we eventually merge the flag types that will be transparent to the user. -- Johan
participants (3)
-
Johan Tibell
-
Mikhail Glushenkov
-
Thomas Tuegel