I don't see why they would need to edit any make files.
I do not think that we ever directly address 10% of platforms where
Harbour can be compiled. It's technically impossible so if we
make build process too complicated to easy adopt it for some more
exotic platforms we block the portability.
For me much more important is easy portability then default Harbour
behavior "out of the box". Just simply I hope that harbour will
be default part of some systems and this is my main goal.
The two goals aren't mutually exclusive IMO.
If there is a setting which needs to be controlled by users
we can provide it through envvars or VAR=VALUE make
parameters.
The problem is that we do not know about such things as long
as someone will not try to build Harbour on new system so
we cannot add them now. Anyhow when the final version of new
.mk files will be ready we can try to document which tools
are required to build Harbour and then try to reduce dependencies
list using some envvars.
Definitely.
The goal of course would be to require the least amount of
such settings.
This is less important. For me the main goal is to be able to build
Harbour in different environment without rewriting .mk files
internals.
I hope that the final version of new .mk files will help in it.
Current state is quite close to final version, at least when
it comes to my part. I hope other developers can extend/fix it,
because my knowledge of different *nix flavors is definitely
narrower than f.e. yours or Phil's. I could only implement what
I saw and understood from already implemented scripts.
I'd still like to address watcom cross-compiler support, but
regarding this area that's the only remaining item pending in queue.
[ package creation scripts are another larger topic, but I haven't
scratched that yet, and maybe I'm not even going to do so. ]
The only such remaining TODO is to autocheck /opt/mingw32ce/bin
for wce cross-builds. Of course unless I missed some bits which
may need to be fixed and cannot be covered by existing means,
which may happen.
I do not understand above. People often have cross build binaries
with some prefix in the PATH so any autodetection will locate them
and enable cross building instead of native compilation.
Or maybe I'm missing sth and you are talking about sth else.
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.
But if everything fits, make_gnu_xmingwce.sh content can be
replaced by single call 'make $* HB_ARCHITECTURE=wce' (or
better be dropped), and make_gnu_xmingw.sh by 'make $*
HB_ARCHITECTURE=win'.
Only if code in .mk files is working and does not have to be updated
for new platform.
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.
With some more work this syntax could be made working for
Windows hosts too, and to also autodetect win watcom
compiler (even on OS/2 or DOS), creating a more coherent
feel. Cross compilation is wider topic than just mingw[arm]
on *nix.
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 :)
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.
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.
OK let's wait with conclusions for the final version of new .mk files.
Then I'll try to make some tests with some more exotic or much older
systems and I'll check if sth has to be changed to make it working.
Okay, thanks in advance.
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.
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?
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
