[PATCH 1/2] makedep: Build Unix libraries with WINE_NO_LONG_TYPES.

[Eric Pouech]

Le 18/02/2022 à 14:53, Jacek Caban a écrit :
> Signed-off-by: Jacek Caban <jacek at codeweavers.com>
> ---
> I don't know if there are other plans for unix libs, but it seems to 
> me that WINE_NO_LONG_TYPES fits them well.
>
>  dlls/bcrypt/gnutls.c | 4 ++--
>  tools/makedep.c      | 6 +++++-
>  2 files changed, 7 insertions(+), 3 deletions(-)
>
Hi Jacek


I'd rather had the impression that Alexandre was more willing to not 
define WINE_NO_LONG_TYPES and push for not using windows long types in 
unixlib when possible

and crossing fingers for not having too many traces in unixlib side

and in last resort, just #define WINE_NO_LONG_TYPES in .c files that 
requires it (ie too many casts)

that what I tried to apply on the ntdll migration proposal, and I didn't 
get any feedback from Alexandre on it...


my small experience on trying to migrate unixlib part

- the int/long mismatch between 32&64 causes the most of the volume of 
changes

- I didn't even think of automating the migration (even by adding casts 
all over the traces & printfs) ; so it's always be painful

- any further optimisations in the migration will be even harder (like 
changing types...), and has in most of the cases larger impacts that 
just the first warnings

- from a personnal standpoint, I'm not willing to make lots of efforts 
into that direction because it requires lots of interaction with 
maintainers of the modules, so it would be way simple for them (and me) 
to do the work


the good side of the proposal

- simplificity and no code changes

- no changes when moving code from PE to unix side


the bad side

- the NO_LONG_TYPES is not a temporary artifact for the migration (but 
I'm not sure someone even believed it)

- from an architectural standpoint, it goes with the choice of being 
able to support transparently any windows type (vs saying the 
transformation must be done before the "syscall" to unix) ; wineserver 
is designed the other way (ie the caller must transform data into a 
windows indepedent format)


minor: tools exec should be also supported (winedump comes to mind) if 
we keep that proposal


so we need to shed some light on what should be the target for Unixlib, 
and your proposal could fit either as the target or as another 
intermediate step to ease another migration


A+
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20220218/efe59fe6/attachment.htm>