On Sun, 18 May 2025, Pali Rohár wrote:
Hello, what do you think about doing one-time automatic deduplication of lib32 and lib-common def files?Since commit cf211ae90565ff02e78c93d93a913501d100f30f ("crt: Remove @<num> stdcall mangling when processing lib-common/*.def.in files for non-I386 builds") Makefile can handle stdcall suffixes in lib-common def files and hence it is possible to have just one def file for all archs, even when i386 requires stdcall @<num>. I was created very simple one-time script which checks if the lib32 and lib-common def files are same after removing the @num in the same way how it is doing Makefile.am. cd mingw-w64-crt for file in `ls lib32 | grep 'def$'`; do if ! test -e lib-common/$file; then continue; fi sed -E 's/^([^ ]+)@[0-9]+( |$)/\1\2/' < lib32/$file > lib-common/$file.tmp if cmp -s lib-common/$file lib-common/$file.tmp; then git rm lib-common/$file git mv lib32/$file lib-common/$file fi rm lib-common/$file.tmp done And it deduplicated 496 def files. What do you think about it? Just a robotic change and can decrease number of def files which needs to be maintained.
Since we did land cf211ae90565ff02e78c93d93a913501d100f30f, and also e128670e1340e1726443394d95726bd6e46ab25f as a first example of doing this, I guess we don't have any reason why we shouldn't do this.
However - the changes in cf211ae90565ff02e78c93d93a913501d100f30f only strip out @<num> when processing .def.in into .def. If I read the snippet above correctly, it keeps files named .def in lib-common, including the ordinal suffix. So if we do this, we'd need to rename the files to .def.in at the same time, right?
// Martin _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
