On Sunday 25 May 2025 12:41:08 Martin Storsjö wrote: > 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
Yes, that is truth. _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public