Signed-off-by: Jacek Caban <jacek@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

- 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+