I gave a quick look to your changes and I would like to suggest a small trick to simplify things.
The preprocessor of GNU tools and CLang provide a keyword called #include_next
.
Sometimes its usage is not recommended, but here it could be useful.
The purpose of this keyword is to include the next file with the same name into the current search order.
For doing a simple example, you patched few files with something like this:
+#ifdef __HAIKU__
+#define SIGIO SIGPOLL
+#endif
Since this change makes me suspect that SIGIO
is undefined into the system headers of HAIKU, you can create a directory and call it for example haiku_wine_utils
.
Inside this directory, create an include
directory and then a sys
directory inside include.
Finally, inside the haiku_wine_utils/include/sys
, create a file called signal.h
with a content like this:
#ifndef __HAIKU_WINE_UTILS_SYS_SIGNAL_H__
#define __HAIKU_WINE_UTILS_SYS_SIGNAL_H__
#include_next <sys/signal.h>
#define SIGIO SIGPOLL
#endif // __HAIKU_WINE_UTILS_SYS_SIGNAL_H__
Now, when you configure WINE, you can add to CFLAGS the path to the tree that you just created with an option like -I~/haiku_wine_utils/include
(obviously, the right path must be used here).
That’s all.
Now, every time the sources will be compiled, the first sys/signal.h
to be included will be the one that you just created, which will call the system header as first task, thanks to #include_next
keyword. Then, it will provide the definition of SIGIO
that will be needed by the sources of the framework.
The same trick can be used for emulating other macros that you wrapped with some #ifdef...#endif
, like ESOCKTNOSUPPORT
/CS6
/CS7
/CS8
/etc…
This could allow to simplify the number of changes and perhaps, if some fixes will be accepted into the codebase of WINE but others not, it can allow to create a package “haiku_wine_utils” that provides some utilities and sources to be used at compile time and without touching the main core of WINE.
You could also “patch” the library functions actually. If you want to “adjust” the behaviour of ioctl()
function, you may add another file like this one:
#ifndef __HAIKU_WINE_UTILS_SYS_IOCTL_H__
#define __HAIKU_WINE_UTILS_SYS_IOCTL_H__
#include_next <sys/ioctl.h>
int haiku_utils_ioctl(int __fd, int __cmd, ...);
#undef ioctl
#define ioctl haiku_utils_ioctl
#endif // __HAIKU_WINE_UTILS_SYS_IOCTL_H__
And, inside a sources that is compiled and added to LDFLAGS of WINE at configure time, you can handle some extra commands not handled by current implementation.
I don’t know how many changes will need WINE to be fully supported on HAIKU.
Perhaps, the number of fixes won’t be so huge.
However, WINE is a software constantly evolving and every time a new version will be released, then an updated patch will need to be prepared, kept up to date and this is a job that somebody will need to do.
Instead, the “utils” will make you free from doing this.
What do you think?
Sincerely.