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
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
