>> One thing is not clear for me. What are these switches
>> doing on non-Intel systems?
>
> Simultaneous runtime support for 32 and 64 bit modes is not only x86
> world feature. Many processors have such capacity, i.e. SUN SPARCs or
> HP PR-RISC machines.
> It's also supported by other then Linux systems like SunOS or HP-UX
>
> Anyhow for some CPUs/systems switches to control 32/64 bit versions
> have slightly different names, i.e. -milp32/-mlp64 on HB-UX or
> -m31/-m64 on S/390 machines.
So I understand this is sort of bit-width only selection,
which is applied to current CPU arch, be it anything which
supports both width and under which current platform is
running.
The idea is still unclear, but this seems to require some
sort of "loose" cpu selection option in hbmk2: -cpu=[32|64|128]
I managed to check on Mac PPC, and it chooses between PPC32
(default) and PPC64, with -m32/-m64. Which fits into the
picture.
This could be used to eliminate msvc64, pocc64, mingw64
and some more targets.
Of course -cpu has to support for strict CPU selection,
like: -cpu=ia64
Plus it would be nice if -cpu would support multi CPU
selection for Darwin: -cpu=32,64,ppc,
>> Next thing to decide is how to control this matter,
>> because if you say that hbmk2 should automatically
>> add -m64 as linker option, it means we're converting
>> -m* switches to hbmk2 ones, and in this case I'm not
>> sure it's the best thing to do. We already have
>> -plat switch to choose these kind of things for win/wce
>> platform, but it's not very good either, so maybe its
>> time to introduce new -cpu switch. This however seems to
>> need more serious redesign of autodetection code in hbmk2
>> and possibly in GNU Make system (and probably more).
>
> There is one important difference between above. It's not
> classic cross build because it's only selection between different
> version of supported binaries anyhow if you what to use different
> hbmk2 switch and well integrate it with other switches then it's
> even beteer.
> Important is only final result which should allow to easy switch
> between 32 and 64 bit modes without writing very long parameter
> list in command line.
> BTW I still have problems to create easy to use hbmk2 configuration
> for different builds.
It needs above "virtual" CPU selection.
>> So for now, to avoid that, the best shortcut is to
>> simply parse HB_USER_CFLAGS for -m64/-m32 and make
>> some internal decisions based on that. It cannot be
>> done in very clean way, but at least I don't have to
>> rewrite the whole thing before release. In this
>> scenario it's users job to pass this switch to
>> HB_USER_LDFLAGS also (but is this really required?,
>> cannot the linker automatically detect the target
>> arch based on input files?).
>
> These switches have to be passed to HB_USER_CFLAGS, HB_USER_LDFLAGS
> and HB_USER_DFLAGS. Now I'm building 32 bit Harbour version in my
> 64-bit Linux using this simple script:
>
> #!/bin/sh
> FLAGS="-m32"
> export HB_USER_CFLAGS="${FLAGS}"
> export HB_USER_LDFLAGS="${FLAGS}"
> export HB_USER_DFLAGS="${FLAGS}"
> # CURL has specific header files which have hardcoded endian and
> # word size information :-(
> export HB_WITH_CURL=no
> make "$@"
>
> and it works very nice if I do not use system wide installation.
> Also hbmk2 even nicely inherits -m32 in hbmk.cfg flags.
I understand.
>> The other remaining thing to see, is how this thing
>> works on other *nix platforms? bsd for example, or
>> even darwin.
>
> In BSD systems probably in similar way just like in SunOS or HP-UX.
> I cannot only say too much about default system directories in this
> systems.
>
>> On darwin / clang and gcc it seems to work similarly
>> to Linux, but I did only try on Snow Leopard / Intel.
>> [ PCC would really be interesting here, but I deleted
>> XCode from my old machine just recently. ]
>
> I have no idea how it may work on Darvin with its existing support
> for mixed PPC and x86 binaries.
Okay, not it only has to be implemented. Since there is no
-cpu support at all in either GNU Make or hbmk2 currently,
and we're before the release, I'm not very comfortable with
the idea, as it may need deeper, even structural changes.
Brgds,
Viktor
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
