[PATCH 1/2] makedep: Build Unix libraries with WINE_NO_LONG_TYPES.
Signed-off-by: Jacek Caban <jacek(a)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(-)
Le 18/02/2022 à 14:53, Jacek Caban a écrit :
Signed-off-by: Jacek Caban <jacek(a)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+
Hi Eric, On 2/18/22 16:51, Eric Pouech wrote:
Le 18/02/2022 à 14:53, Jacek Caban a écrit :
Signed-off-by: Jacek Caban <jacek(a)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...
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.
- the NO_LONG_TYPES is not a temporary artifact for the migration (but I'm not sure someone even believed it)
It would need to stay even if we applied it only for selected few files. And it seems worth keeping as an option for winelib anyway.
- 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. Thanks, Jacek
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. A+
Eric Pouech <eric.pouech(a)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(a)winehq.org
participants (3)
-
Alexandre Julliard -
Eric Pouech -
Jacek Caban