[I'm going to try to only respond to the technical sides of this] On 2012-10-09 22:51, Roumen Petrov wrote: > Peter Rosin wrote: >> On 2012-10-08 23:29, Roumen Petrov wrote: >>> Peter Rosin wrote: >>>> Hi Roumen, >>>> >>>> On 2012-10-07 11:37, Roumen Petrov wrote: >>>>> And now test fail in cross environment : linux for mingw host >>>> Thanks for the report! >>>> >>>> I have pushed this. Let me know if it doesn't help. >>> No comment. >> Thank you, I'm assuming it finally works for everybody. > > Did you think that world to follow you stupid patches ?
I'm not sure how I should parse that, but are you saying that you have not checked if git-master works for you after the last change? > It is enough do throw out you commits to bring system in stable state again. No, because reverting them leaves the testsuite broken on Windows. That's not stable. >>> Ralf wrote so good code I cannot understand any Peter's patches. >>> Why you just don not use existing working fine macros ? >> Please, make a useful suggestion instead of hand-waving it like >> that. What working macros should I use? I also don't see where I'm > > You even didn't wait 72 hours for feedback !!!!!!!!! > > Each of you recent "obvious (!!!!!!!!!!)" patches break libtool. I apologize for breaking things for you, and I hope that I have repaired it. However, I will defend my changes with the fact that the testsuite was broken before I committed anything, and that I consider the whole testsuite to currently by in an abnormal state of flux after the big changes by Gary, which relaxes the commit rules considerably. My commits fixes real problems, and if the testsuite is working for your linux->mingw setup as of now (which is unclear, please test), then it is apparent that it will not work for you if you yank all my patches from the last month or so. >> introducing any new macros, can you please point that out for me? >> And Ralf must write very special code indeed if his code somehow >> makes it impossible for some to read the code others write. >> [Ralf, if you're reading this, I hope you understand that I don't >> think that's true, you write very good code, period] >> >> >> In this particular case, >> >> LT_AT_HOST_DATA([expout], >> >> doesn't work as it creates \r\n newlines in expout, and $EGREP futzes >> the newlines on MSYS so that the standard output ends up \n, causing >> the test to blow up. >> >> AT_HOST([expout], >> >> doesn't work as $EGREP leaves the newlines alone for Linux->MinGW >> (at least that's what I deduced from your report), and then you >> have \n in expout and \r\n in standard output. And the test blows up. >> >> Either that, or I misread your "And now test fail in cross >> environment : linux for mingw host" message. I read it as if the >> test worked without my patch changing LT_AT_HOST_DATA to AT_HOST, > > Exactly . > >> and that the test failed with the patch. > Exactly after you fluctuations . > >> That message made me >> assume that neither LT_AT_HOST_DATA nor AT_DATA works for this >> test (and the only thing different in this test is that $EGREP >> is used). > > You must investigate more why in this particular case LT_AT_HOST_DATA fail in > you environment . LT_AT_HOST_DATA does not fail, it creates \r\n line endings just fine. It is then a fact that in MSYS "/bin/grep -E" clobbers the newlines to \n, while on your Linux system that doesn't happen. I'm sure there are good reasons for the MSYS grep to use text mode. So, in this case LT_AT_HOST_DATA is unusable as is, since it doesn't know whether to create \r\n or \n line endings. >> So, the newlines has to be normalized after the $EGREP, or the >> test has to be rewritten in a deeper way. > > Take care that LT_AT_HOST_DATA is used more then once ! So is LT_AT_UNIFY_NL, what's your point? LT_AT_UNIFY_NL is for when the line ending style is hard to predict, as in this case. BTW, do you realize that I added the LT_AT_HOST_DATA invocations that you are now championing? >> And, as it happens, Ralf did not write the code I'm changing here, >> it was written by Gary when he thankfully eradicated the legacy >> testsuite, so I'm not sure why you're dragging Ralf into this? > You just wrote to the world that you don't know author of LT_AT_HOST_DATA ! > > "Ralf did not write the code I'm changing here" - ha ha ha . Well, it's a fact that Gary wrote the code I'm changing. Ralf may have written the LT_AT_HOST_DATA macro (I don't know), but I didn't change that, did I? It was also I who changed AT_DATA into LT_AT_HOST_DATA, but after clearing up another problem in the vicinity (thanks Gary), it became apparent that LT_AT_HOST_DATA was not the correct fix in this case (as described above) so I reverted it. Then you reported that your cross environment didn't match the native environment, and that a different method was needed, and I went with LT_AT_UNIFY_NL. I don't even remember writing that macro some years back, but git blames me so I guess I'm guilty. Apologies. Cheers, Peter
