NUKE MinGW GYP - #24
Conversation
Co-authored-by: slipher <slipher@protonmail.com> An AI has been used to parse the GYP files and the GYP build logs to produce some Makefile.am template mimicking the GYP behavior. That template has then been manually adapted to fit with the original Makefile.am file.
|
On my end |
slipher
left a comment
There was a problem hiding this comment.
I added one fixup commit for the crash_generation_app resources to your branch. With that fixup commit plus #25 everything builds OK.
make check results:
PASS: src/processor/address_map_unittest.exe
PASS: src/processor/contained_range_map_unittest.exe
PASS: src/processor/disassembler_x86_unittest.exe
PASS: src/processor/basic_source_line_resolver_unittest.exe
PASS: src/processor/cfi_frame_info_unittest.exe
PASS: src/common/test_assembler_unittest.exe
PASS: src/processor/map_serializers_unittest.exe
PASS: src/processor/minidump_processor_unittest.exe
PASS: src/processor/fast_source_line_resolver_unittest.exe
PASS: src/processor/exploitability_unittest.exe
PASS: src/processor/minidump_unittest.exe
PASS: src/processor/static_address_map_unittest.exe
PASS: src/processor/static_contained_range_map_unittest.exe
PASS: src/processor/pathname_stripper_unittest.exe
PASS: src/processor/static_map_unittest.exe
PASS: src/processor/static_range_map_unittest.exe
PASS: src/processor/microdump_processor_unittest.exe
PASS: src/processor/postfix_evaluator_unittest.exe
PASS: src/processor/proc_maps_linux_unittest.exe
PASS: src/processor/range_map_truncate_lower_unittest.exe
PASS: src/processor/range_map_unittest.exe
PASS: src/processor/range_map_truncate_upper_unittest.exe
PASS: src/processor/stackwalker_amd64_unittest.exe
PASS: src/processor/stackwalker_arm_unittest.exe
PASS: src/processor/stackwalker_arm64_unittest.exe
PASS: src/processor/stackwalker_address_list_unittest.exe
PASS: src/processor/stackwalker_mips_unittest.exe
PASS: src/processor/stackwalker_mips64_unittest.exe
PASS: src/processor/stackwalker_x86_unittest.exe
PASS: src/processor/synth_minidump_unittest.exe
FAIL: src/client/windows/unittests/client_tests.exe
PASS: src/processor/minidump_dump_test
PASS: src/processor/microdump_stackwalk_machine_readable_test
PASS: src/processor/microdump_stackwalk_test
PASS: src/processor/minidump_stackwalk_machine_readable_test
PASS: src/processor/minidump_stackwalk_test
============================================================================
Testsuite summary for breakpad 0.1
============================================================================
# TOTAL: 36
# PASS: 35
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
7a8e7be to
5ebb112
Compare
|
Speaking of the
The But then after this PR we would have removed the GYP infrastructure to build |
fdfa7e5 to
bbb06cd
Compare
|
I added some commits to make the checks run on Wine. A Windows test would be welcome to check that Here are the check results on my end, on Wine: The check run is very slow (and wine initialization makes it even slower). Even with parallel tasks, it lasted 11 minutes. |
24123ea to
3c42216
Compare
|
I did a small mistake in the I now get the same results as you @slipher: This time it lasted 5 minutes (but maybe I had not cleaned-up the checks). |
Interesting. On my fairly old Windows laptop, a parallel
We lack the interest and ability to maintain any MSVC-exclusive targets, so NUKING seems fine given that we are going to sync upstream. Someone who wants to build those should use whatever upstream provides. But then we may be missing some non-MSVC-exclusive bits. The "MS symbol server" stuff was hacked upon by Jon Turney so maybe it is relevant.
With the latest version of the PR, the script reports 36 failures. In the test log it looks like some of the test binaries failed to start, while others ran but were reported as failing for whatever reason. In any case it would be preferable to move Wine stuff to a new PR. |
3c42216 to
953b5fc
Compare
There was something missing to detect (non) Windows. So all test would have failed by expecting Wine. |
b87457e to
31563fb
Compare
|
About the slowness one wine. A lot of that slowness is expected as it is safer to use a throw-away Wine prefix for running tests, but each test can run on parallel, so we better attribute one to each of them, and then for 36 tests we would set up 36 wine prefixes, copying 1.3G of wine files in each of them, plus running wine initialization software in each of them… So that can explain that a lot of time is spent on tests, though that init time should be partially parallelized as well… I added an environment variable named Something good to know is that this test triggers some very deep failures in Wine, spawning some Wine crash handler and backtrace… That would explain some of the slowness. But that's not the only test that is slow. When run in parallel, the line result of a test comes in the bottom of the list when it ends last, even if it ends with success: So here is the log of the |
|
Here is an example of Wine going bad, it would be useful to know if that specific test runs properly on Windows or fail as well: |
31563fb to
0565b8c
Compare
Yes, but I needed it to test my PR, now that the PR stabilized, the Wine stuff can be found there: |
693c867 to
a76125f
Compare
|
When building with GYP every test pass (here on Wine with static builds): |
|
Ah no, the GYP build is not running |
|
Hu no the checks were just autoconf builds, GYP writes tests as |
|
Actually the GYP-built not only fails, but fails more: Automake: GYP: |
a76125f to
956f576
Compare
|
With |
956f576 to
b77e57b
Compare
|
Assuming some errors come from Wine implementation, I ran the static MinGW-built Details: |
b77e57b to
4e56204
Compare
|
LGTM to:
|
4e56204 to
74ead57
Compare
|
I removed the This doesn't remove the MSVC gyp stuff and then the tooling around, this will be taken care when merging upstream. |
1743ca3 to
4da3b68
Compare
|
@slipher here is what I propose for disclosure in the commit message: |
|
LGTM |
NUKE GYP.
Disclaimer: the
Makefile.amwriting has been assisted by ChatGPT. By feeding the bot various dumps of GYP files, files generated by GYP and list of built files, and by iterating through some trial and errror process (mainly to fix some linkage ordering).