Alexandre Julliard wrote:
> Ulrich Weigand <[EMAIL PROTECTED]> writes:
>
> > Well, the IMO most important configure checks are CPU architecture
> > and OS specific (e.g. location of system headers / libraries and the
> > like). While there are of course also compiler / toolchain dependent
> > checks, those should matter only to the build process itself, and not
> > the header files.
>
> I disagree; the important configure checks are the ones that matter to
> the build process. configure is very useful to determine headers
> location, which libraries contain which symbols etc. and this is what
> it should be used for.
I was a bit unclear; of course the use of configure checks in the
build process is important. But these are irrelevant to the question
whether we should install a config.h with the Windows system headers
(and what it should contain).
What I was trying to say is that *those* configure checks that are
important *for use inside the Windows header files* are mostly CPU
and OS specific, not compiler / toolchain dependent. This was in
response to Patrik's argument that we might need different config.h
versions for different compilers / toolchains ...
> Architecture differences do not need configure
> checks, all the #defines we need are already part of the compilation
> environment (__i386__, __sparc__ etc.)
Would you prefer, then, to have things like endianness be decided
by explicit check for certain, named, architectures instead of
via a generic configure check? We could have a section in, say,
windef.h setting those defines, e.g.
#if defined(__i386__)
#undef WORDS_BIGENDIAN
#undef BITFIELDS_BIGENDIAN
#define ALLOW_UNALIGNED_ACCESS
#elif defined(__sparc__)
#define WORDS_BIGENDIAN
#define BITFIELDS_BIGENDIAN
#undef ALLOW_UNALIGNED_ACCESS
#else
#error Unknown CPU architecture!
#endif
This has the disadvantage that it can't automatically cope with
new architectures, but then again, for any new architecture,
there are lots of places that need to be adapted anyway ...
> > Cross compilation doesn't work anyway, and it does not appear easy
> > to set up the build process for it. Why do you think it important?
>
> Cross compilation can be useful in many cases, especially for embedded
> systems, and is actually quite easy to support if we do things right.
Well, but on which embedded system do you want to run Wine? ;-) Every
system powerful enough to run Wine should also be able to run the
compiler and toolchain ...
> The main obstacle is that our tools (winebuild, wrc) should not
> use #ifdefs but run-time checks instead. But that shouldn't be too
> hard to fix.
We'd have to pass an explicit 'target' argument on the command line,
for example. But in my experience, the main problems with cross
compiling tend to be in the area of the build environment:
which files have to be compiled natively, which cross (e.g. we'd have
to compile two versions of libwine_unicode, one native for the tools
to use, and one cross for the target libwine to use); how to determine
correct configure settings for the target; how to find correct target
headers and libraries etc. No real tough problems, just tedious ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
