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

[Alexandre Julliard]

Eric Pouech <eric.pouech at orange.fr> writes:

> Le 20/02/2022 à 12:35, Jacek Caban a écrit :
>
> 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...
>
>  I think that using WINE_NO_LONG_TYPES only for some files in a module is not pretty. It would make it no longer easy to know which type we're using when touching the code. It also may be confusing to things like LTO.
>
> agreed. I'm even thinking we should be homogenous across all unixlib
>
>  - 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
>
>  I generally think that reasons for using ints for LONGs before PE migration still apply to Unix libs. It's very convenient to have the same builtin types for LONGs on 32-bit and 64-bit targets. We could probably avoid this for Unix libs using __wine_unix_call, which have more flexibility and could mostly avoid using LONGs on Unix side. But I think that modules like ntdll or win32u which need to
>  deal a lot with Windows types will be better with WINE_NO_LONG_TYPES. My patch uses it for all Unix libs, which was motivated by more consistency. It seems to me like a good approach, but I'd be fine with other solution as well.
>
> No strong feeling either way. But we need a clear direction.
>
> Let's wait for Alexandre view on this.

My thought was to make it opt-in since most Unix libs shouldn't need it,
but I can see an argument for making this the default behavior.

If we do that, I'd suggest to do it directly in the headers instead of
hacking makedep. Ultimately, maybe the #ifdefs should be replaced by
__WINE_USE_MSVCRT.

-- 
Alexandre Julliard
julliard at winehq.org