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
Very nice, so it's already working.
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.
Good for me.
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.
Okay.
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.
Thank you.
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.
I agree with these. As for autoconf, if it can be used as a simple
tool to generate such config header as a pre-make step it can be nice,
but unfortunately autoconf is a *nix only tool, so it will be again
something which will have to be rewritten for non-*nix platforms,
and/or we will have to reintroduce parallel systems (*) for the same
thing for different platforms. I've yet to see what is the "magic"
of autoconf, but if possible I'd try to go in a direction which
is portable (like some .mk detection logic if it's possible to do).
(*) like we currently have for .dll generation f.e.. Which in order
to have equal support for all GNU Make scenarios, would have to be
written in each shell language for every arch/comp combination. And
maintained in parallel. This is in practice impossible, difficult to
test and error prone. This isn't ideal and that's one reason I try
to move functionality on the GNU Make level where possible.
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.
Probably limits exist, we just don't know them. We don't have to
limit ourselves I agree, but some practical limit must exist whether
we want it or not. We don't support Win32s probably and I don't
know just guess, that Linux 1.x kernels wouldn't work either. As
you say Darwin support should also be revised, because f.e. I
for example only test it on latest systems, but it's normal that
users are using 1-2 generation older versions.
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.
'real final version' :) okay, please consider current state as
pretty much it. I can't promise I won't have any new idea along
the way, but I've about reached the end of my TODO list, so no
huge things are planned. Anyway it'd be probably nice to wait
a few weeks as testing / proving time for latest changes.
I planned to move dynamic enabler logic from central location to
a lib level flag. But unfortunately harbour dll related lib lists
still need to be maintained in a few places so I didn't make it
yet.
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.
So back to PLATFORM vs. ARCHITECTURE, I'd definitely vote for
PLATFORM. We're using it for __PLATFORM__* macros already, plus
that's the more accurate description of "OS". ARCH usually has a
CPU connotation with it, which makes it misleading, since we
specifically avoid making any of our platforms CPU specific.
We also use 'platform' or OS in any human readable texts. "HB_OS"
would also be good, but it's just too short for easy grepping.
I'll probably gather current usages to get a better picture of
our term usage.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
