On Tue, 18 Aug 2009, Szak�ts Viktor wrote:
> I'd still like to address watcom cross-compiler support, but
> regarding this area that's the only remaining item pending in queue.
For me it works quite well. I only have to set:
export HB_ARCHITECTURE=dos
export HB_COMPILER=watcom
export HB_INSTALL_PREFIX="$(pwd)/out-${HB_ARCHITECTURE}/${HB_COMPILER}"
# eliminate libraries which scans for local host header files
export HB_XBUILD=yes
> Currently you have to *ask* for a cross-build on Linux by using
> HB_ARCHITECTURE=[win|wce]. If you asked for it, cross-build specific
> tools will be searched, HB_CCPATH and HB_CCPREFIX will be taken
> into account (here probably some more setup combinations could
> be accepted, like accepting plain HB_CCPREFIX). This is somewhat
> different behavior than on win, where make system assumes that
> only one compiler tool is present in the PATH at the same time
> and the set of tools to work with is pretty much static.
> We can tweak this, but currently it's done that way.
For me the *nix behavior is OK and I would like to keep it.
> Please check the code, maybe it tell more than me trying to
> explain it. Current win/wce cross-detection and setup code
> in .mk works for all platforms (*nix OSes). Of course it
> may happen that the autodetection list needs to be extended
> (although I replicated the .sh logic as much as I possibly
> could), but even autodetection can always be overridden by
> manual HB_CC* values. So there shouldn't be such case when
> user has to delve into .mk files.
As long as manual overwritting works it's OK.
>>> Maybe it's time to create a cross-build matrix to document
>>> all supported cross build combinations.
>> It's rather not possible. There are too many different combinations
>> and we are supporting only few of them.
> Most probably. BTW, it would very nice if you could give us
> a broader overview on possible *nix scenarios. You mention this
> a lot, but to me the picture is quite dark, so I can't really
> do anything with this fact in practice. Probably some teaching
> would be good here :)
These are available for SUSE Linux directly as RPMs:
cross-i386-gcc
cross-x86_64-gcc
cross-ia64-gcc
cross-ppc-gcc
cross-ppc64-gcc
cross-s390-gcc
cross-s390x-gcc
cross-hppa-gcc
cross-mips-linux-gcc
cross-arm-linux-gcc
cross-avr-gcc
cross-spu-gcc
cross-mingw32-gcc
cross-mingw64-gcc
Additionally many of them can use different binary incompatible ABI and/or
libc libraries so you have to multiple them by different combinations
like embed-gnueabi.
Just look at
http://software.opensuse.org/search
at type
-gcc
in [search] area and look at the results and please remember that
not all combinations are supported directly by SUSE RPMs and this
list is not full yet.
> As another note: We should probably define our limits/boundaries
> regarding what system configurations we *want to* support in
> Harbour. This would have clear practical benefits since we could
> focus on that except focusing on the infinite, which is pretty
> much impossible anyway.
Yes. It's very simply:
1. Little or big endian CPUs (though if necessary we can add support
also for PDP endian machines),
2. ASCII based character encoding (we do not support EBCDIC so it will
be hard to port Harbour to some IBM machines and it's not trivial
mechanical job to add such support if we want to think about binary
compatibility in some places like database files) which uses
3. 8-bit 'char' type with multiple types (16/32[/64]). It also reduce
portability to some machines but to eliminate it it's necessary to
make serious cleanup in code. As in point 2 the biggest problem
is binary compatibility in database files. In some cases it's
even necessary to create new formats which will play well with
available numeric types.
Except point 1 which can be easy added locally quite fast the 2 and 3
points needs deeper modifications and I do not have enough motivation
to work on it at least of free.
All other systems should be supported and we do not have to limit them
in any way or hardocde CPU name in our make systems. The most important
feature of open source software is the fact that it comes with source
code so can be easy recompiled using current and new platforms in the
future.
The problems can appear yet in detecting support functionality.
For *nixes we need only vary basic POSIX compatibility for ST
builds and PTHREAD support for MT builds. Because PTHREAD may
not be available then we should have an option to recompile
Harbour without MT support.
We do not use autoconf so we have to guess what is available
on given platform. It creates potential problems in portability,
i.e. to older systems. I guess that current Harbour cannot be used
with older MacOSX or Linux builds. Now I'm trying to cover all
extended functions usage by HB_HAS_* or HB_USE_* macros.
In the future I plan to group them in one header file which can
be easy edited by user and/or overloaded (redefined) by autoconf.
I do not have to even know the system name. Clean configuration
should work with SCO, UNIXWARE and other *nixes not explicitly
supported by us. Probably we will have to add generic POSIX/UNIX
platform support to our .mk files.
> This would also be an important part of Harbour documentation,
> what Linux/Darwin/* kernels we support, what CPUs, what are the
> requirements at build time (shell, tools, etc), what are those
> at runtime. Same for OS/2, Windows, WCE. Currently we have no
> clear boundaries.
I do not agree. Just simply I do not see any reasons to introduce
limits for users. We can only document where we tested it. That's
all.
> You mention old systems: Please see some NOTE/TOFIX comments in
> global.mk on GNU Make keyword usage and required GNU Make version.
> Looks that 3.78 is the oldest we can practically work with (since
> long, not because of my latest changes), the rest may be fixed.
I'll look at it but I'll wait for real final versions.
It's hard to follow or your modifications.
>>> If we don't rely anymore heavily on manual HB_COMPILER and
>>> HB_ARCHITECTURE settings, I also plan to rename the latter
>>> to HB_PLATFORM. (or maybe to short versions HB_COMP and HB_PLAT).
>> HB_ARCH
> Sorry, what did mean here?
A short versions proposition.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
