H.Merijn Brand venit, vidit, dixit 19.02.2015 12:14: > On Thu, 19 Feb 2015 11:33:01 +0100, Michael J Gruber > <git@xxxxxxxxxxxxxxxxxxxx> wrote: > >> Jeff King venit, vidit, dixit 18.02.2015 19:57: >>> On Wed, Feb 18, 2015 at 10:47:16AM -0800, Junio C Hamano wrote: >>> >>>>> It seems like we could use >>>>> >>>>> (cd src && tar cf - .) | (cd dst && tar xf -) >>>>> >>>>> here as a more portable alternative. I don't think we can rely on rsync >>>>> being everywhere. >>>> >>>> Thanks; I wasn't even aware that we used rsync in our tests. We >>>> certainly do not want to rely on it. >>> >>> I don't think we do. >>> >>> Grepping for rsync in t/, it is mentioned in three places: >>> >>> 1. In t1509, we use it, but that test script does not run unless you >>> set a bunch of environment variables to enable it. >>> >>> 2. In a sample patch for t4100. Obviously this one doesn't execute. :) >>> >>> 3. In t5500, to test "rsync:" protocol supported. This is behind a >>> check that we can run rsync at all (though it does not properly use >>> prereqs or use the normal "skip" procedure). >>> >>>> Why not "cp -r src dst", though? >>> >>> I was assuming that the "-P" in the original had some purpose. My "cp >>> -r" does not seem to dereference symlinks, but maybe there is something >>> I am missing. >>> >>> -Peff >> >> There's a symlink in sub that needs to be preserved. >> >> I'm cooking up a mini-series covering tar/cp -P so far and hopefully the >> JP encodings later. Do I understand correctly that for Merijin's use > > Merijn, no second j. You can also call me Tux, as that is what the perl > people do just because of that :) > >> case on HP-UX, we want >> >> - as few extra tools (GNU...) as possible for the run time git >> - may get a few more tools installed to run the test > > You can require as many GNU tools for testing as you like: I'll install > them. I just need to be sure they are not required runtime. (tar, cp) > >> I still don't have a clear picture of the iconv situation: Does your >> iconv library require OLD_ICONV to compile? > > No > >> Is there a reason you want to disable it? > > Yes, if I build a package/depot, and the package depends on iconv, it > is highly likely to fail on the client side after installation, as I do > not control the version of iconv/libiconv installed. > > As HP does not have libiconv installed by default, I have experienced > many tools to be unusable after installation because of that dependency. > > Another reason is that I built 64bitall, as my CURl and SSL environment > is 64bitall for every other project on these systems (including Oracle > related, which *only* ships 64bit objects on HP-UX) and the OpenSource > repos for HP-UX only ship 32bit software (sad, but true). That implies > that I cannot require libiconv.so to be present on the client side. > > I'd like my git to be as standalone as possible OK, so we should use NO_ICONV on HP_UX then. >> Failing so many tests with NO_ICONV is certainly not ideal, but I'm not >> sure we should care to protect so many tests with a prerequisite. > > How feasible is it to isolate those tests into separate test files that > people that know to not use e.g. Asian can safely ignore them? > >> Michael We have the prerequisite mechanism for that, and most probably, the tests are "isolated" already, in the sense that with NO_ICONV, only trivial setup tests succeed for those test files but all "proper" tests fail. But I'll check. Need a good test to set the prerequisite, though. Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html