Patrik Stridvall ps@leissner.se writes:
Patrik Stridvall ps@leissner.se writes:
We could do that following instead: (1) /usr/include/wine => /usr/include/wine/windows (2) /usr/include/wine/wine => /usr/include/wine/windows/wine (3) /usr/include/wine/wine/wine => /usr/include/wine
Also note (2) will disappear eventually.
Well, it's somewhat better, but it's still too complex IMO.
Where is the complexity?
The complexity is that you create up to 3 levels of directories under /usr/include, I don't think such a deep hierarchy is really necessary.
I can't see any principal difference between /usr/include/wine_foo.h or /usr/include/wine/foo.h
Well, the difference is that you can then use /usr/include/wine for the Windows includes.
Of course compiling every DLL with the Microsoft headers requires fixing all of include/wine/ but then as long as we have a solution when we get where eventually is good enough IMHO, doing that is no particular rush. Having the Wine tests work properly sooner rather than later is much more important though.
I agree getting the Wine tests to work soon is important, but you don't really need the final header organization for that; you can easily work around the current problem by copying files around or specifying an absolute -I option.
I don't think we have found a fully satisfying solution yet, and IMO the situation will be clearer when the dll separation is finished and the loose ends are cleaned up, so I'd prefer to wait until then to decide on the final structure. (And my secret hope is that by then we will be able to switch to Subversion which should make renaming files a lot easier; but that's another topic...)