-
Notifications
You must be signed in to change notification settings - Fork 6
Allow to gradually remove the auto-tester patching #8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
This is one option. The underlying issue(s) need to be tackled, and a number can probably be directly addressed. As far as the referenced pr's go, I still object to parts of them but would have to re-review to recall details. Regardless, I'm about to leave town for a week and have a rule to not make changes that aren't absolutely necessary before traveling. So, this will all wait until after returning. |
Yep. You don't like it? Do you prefer something else?
Fair enough, but that's independent to this PR (i.e. the process of removing the patching).
I hope you had pleasant Christmas & holidays! |
|
Ping @braddr - so what's your opinion on this? I would love to start moving away from the win32+64.mak files... |
|
Ping. If you don't like grabbing for a string. How about a dedicated file or do you have something else in mind? |
|
Friendly ping about this ;-) |
|
ping @braddr can you please help us unclog this |
|
Sorry for taking so long to get back to looking at this. Re-reviewing the changes, the problem I have is that it looks like this strictly providing an off switch that it looks for in the win64.mak file for each repo. I'm not sure I see how that facilitates gradual anything. I see how it facilitates ONE step, which might be enough. What am I missing? As an aside, cut out the hyperbole, it's not almost impossible to edit the make file, as is manifestly obvious by the number of changes it's had over the years. |
Well how else would you do it? |
|
Ping @braddr - so how can we move forward here? |
|
The simple solution would be to include @braddr's patches in the repo right? |
We can't do that, because it still results in merge conflicts as the patch can't be applied. Also AFAICT @braddr doesn't want to open 10 pull requests (for each repo x |
|
Sounds like we've painted ourselves into a corner :) |
Yes, but I still have hopes that we can find a way to remove the patching by auto-tester. |
|
@braddr see https://github.com/dlang/dmd/pull/7968/files#diff-180360612c6b8c4ed830919bbb4dd459R56 for an example how to build and run the test suite with compiler overrides without patching the makefiles or d_do_test. We can also add targets to the makefiles to simplify that for the auto-tester. |
Yeah and it would be a lot easier to do with if we have a way to disable the patching within the PR.
Friendly ping. |
pong. |
|
Another PR that is lingering in the queue due to the patching errors is dlang/dmd#7414 |
The patching done by the auto-tester makes edits to the
win64.makfiles nearly impossible, see e.g. the famous dlang/phobos#2526 (oldest non-merged PR at Phobos) or more recently dlang/phobos#5940.Hence, I propose to check for a
NO_AUTOTESTER_PATCHING_V${diffVersion}_${repoName}string, s.t. we can gradually remove these patches.Should it become necessary to introduce patching again in an unlucky future, you can simply bump
diffVersion.