I just emailed Ruben a fix for this. The fix is essentially to turn whitespace handling off when processing attribute values, which do not require the same special handling that element values/text nodes do.
On Mar 29, 5:11 pm, Ruben Willems <[email protected]> wrote: > Hi > > this is indeed a work around, so that's a plus. > I made a unit test for this, and could simulate it, and that's the good > news. > > the bad news is : I can not fix it :-( > > this is really complicated code. > > What I did find is the following : there is an option in the pre-processor : > IgnoreWhitespace > > and it seems to be hard-coded to true. > When I put this value to false, I get an unused node detected error, but I > could not find out where. > > the base problem is the following : > ° $(myPort) $(myUser) $(myPassword) is the value of buildargs > ° in the first run of the pre-processor this gets processed to : > the lazy fox > ° next the pre-processor tries to parse this again, and now the problem > arises. > the space gets translated via _ProcessTextNode like this : > if (_Env._Settings.IgnoreWhitespace && node.Value.Trim().Length > == 0) return _emptyNodeSet; > ° the caller of this method does an addRange, and now it seems that adding > an emptyNodeSet (which is just an empty array) > is in fact the space killer > > so the fix should be to set the IgnoreWhitespace to false, and fix the bug > in the preprocesser. > maybe the problem is in fact an overflow detection somewhere, but with a bad > error message ? > > looking further into this, but any help appreciated :-) > > test is committed to the trunk. > > with kind regards > Ruben WillemsOn Mon, Mar 28, 2011 at 10:12 AM, parrimore > <[email protected]> wrote: > > Hi, > > > We're seeing a related issue, though it's basically the opposite problem in > > that whitespace is being stripped under 1.6 when it wasn't in 1.5. We have > > various bits of config files that look something like this: > > > <exec executable="foo.bat" > > baseDirectory="$(myBaseDir)" > > buildArgs="$(myPort) $(myUser) $(myPassword) $(myWorkspace)" > > description="Foo" /> > > > Unfortunately under 1.6 it has started stripping out the spaces in the > > generated buildArgs, ie. as if we'd written > > "$(perforceArtServerPort)$(perforceArtUser)$(perforceArtPassword)$(perforceArtWorkspace)" > > instead. The only way I could get it to work was to rewrite it like this: > > > <exec> > > <executable>foo.bat</executable> > > <baseDirectory>$(myBaseDir)</baseDirectory> > > <buildArgs>$(myPort) $(myUser) $(myPassword) > > $(myWorkspace)</buildArgs> > > <description>Foo</description> > > </exec> > > > I'm not really sure why that should make any difference though! > > > As 1.6 sadly didn't provide the change I'd hoped for after reading the > > build notes anyway, we've simply rolled back to 1.5 for now. > > > On Tuesday, February 15, 2011 6:55:25 PM UTC, Craig Sutherland wrote: > > > Just a quick update on this - it is due to changes in the pre-processor. In > >> 1.5 it was (incorrectly) stripping out whitespace, which made it > >> impossible > >> to put newlines, double spaces, etc. in an argument. In 1.6 this problem > >> was > >> fixed but now it breaks older configurations :-( > > >> We are looking into what we can do about this and hopefully will come up > >> with a solution soon, > > >> Craig
