(In reply to Marco Trevisan (Treviño) from comment #9)
>
> We've currently "fixed" it by using a workaround at CMakeFile level, but I
> guess reverting the commit and adding a --unquoted-variable cmd line would
> be the best choice to do to avoid breakage.
What I'd be doing here would be reverting so that --variable had the behavior it's had since it was introduced years ago except in the case that the value appears to be quoted.
For your downstream case, you could revert that change and depend on pkg-config-0.29.1 (or build-conflict with pkg-config-0.29). But I really think this is a regression and the proper fix is to change back to the original behavior as much as possible. Unfortunately, that makes this particular case more difficult, but people using such complex values in variables is almost certainly a rarity.
I'm going to apply this and release 0.29.1 with it. Please reopen if you need something else to handle this correctly (e.g., a special --unquoted-variable or such).
(In reply to Marco Trevisan (Treviño) from comment #9)
>
> We've currently "fixed" it by using a workaround at CMakeFile level, but I
> guess reverting the commit and adding a --unquoted-variable cmd line would
> be the best choice to do to avoid breakage.
What I'd be doing here would be reverting so that --variable had the behavior it's had since it was introduced years ago except in the case that the value appears to be quoted.
For your downstream case, you could revert that change and depend on pkg-config-0.29.1 (or build-conflict with pkg-config-0.29). But I really think this is a regression and the proper fix is to change back to the original behavior as much as possible. Unfortunately, that makes this particular case more difficult, but people using such complex values in variables is almost certainly a rarity.
I'm going to apply this and release 0.29.1 with it. Please reopen if you need something else to handle this correctly (e.g., a special --unquoted-variable or such).