Use explicit include opt for perl calls. #3496
At the top, perl is called using with the "-Isrcdir" option, and it works: https://github.com/curl/curl/blob/master/tests/runtests.pl#L182-L183 But on line 3868, that option is omitted. This caused problems for me, as the symbol-scan.pl script in particular, couldn't find it's dependencies properly: https://github.com/curl/curl/blob/master/tests/runtests.pl#L3868 This patch fixes that oversight by making calls to perl sub-shells uniform.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel your pain. I've spent countless hours tweaking my own Travis config so it runs reliably. I had to write logic to retry apt updates/installs, and then cache the deb packages in a standalone stage. Otherwise a hash mismatch, or particularly slow mirror, would slow down my build enough that it would fail. I found the:
addons: apt: config: retries: true
To be useless. i can send you what I've been using, if you're interested.
And after all the effort to overcome apt problems, I still see builds failing because the gcc-8 + -O3 jobs occasionally time out. Normally that build variation takes~46 minutes, but if GCE is a little sluggish, the slowdown is enough for the job to hit 50 minutes... and I still haven't figured out a solution to that problem yet.
I have another Travis project whose sole purpose is checking various cloud hosted URLs, downloading the file, and verifying the hashes. If the downloads run single file, the script times out. If I separate each URL into its own job, I hit the 200 job limit. If I try running all of the jobs in parallel, a handful will fail,
And I added the following to my configs as well. It will prevent a build from timing out for lack of output, and I find the load average information helpful in determining whether a problem is a load problem, or something else:
I'm rambling. I only wanted to say I kicked off:
And so far, which was my original patch, (and what I've been using locally), and while the Travis job isn't done yet, so far it appears to be working.
That's because the Travis builds slow down so much devs see weird curl / network / SSL errors which have nothing to do with us.
The problem was the missing space
so try "$perl "
@jay I wasa about to say I already tried that:
But I gather you're saying there needs to be a space after the variable name ... aka "$perl ";' ... I'll commit it when the current build finishes, so it doesn't get cancelled.
As for the other issue, I agee, it's wasn't a question of "fault." I was having trouble figuring out why
I couldn't figure out the cause either. My eyeballs suggested the output matched expected. My only theory is that ActivePerl might be doing something weird.
@jay can you trigger an AppVeyor rebuild? I'm curious about whether the same errors will repeat. If they do, then there may in fact be an issue. In which case I'd suggest going with the original submission.
Thanks. We have a feature window but this is a bug fix so there is no need to wait. If you have any submissions ready don't wait for a window let us worry about that just submit and someone will take a look and determine how to proceed. However if you have features you haven't finished working on yet I suggest discussing it on the appropriate mailing list so you can get some idea of how they will be received before you spend time.