Hi Przemek, Tamas and All,
After reading the conversion now I totally don't
understand what is the situation with LLVM-GCC.
[ Notice that I've committed patch for
CPPFLAGS/CFLAGS issue today, so now we have only
CFLAGS, and no leakage into linker flags. ]
Looking at attached .mk file, it applies these
settings:
HB_CCPREFIX=llvm-
HB_USER_CFLAGS=-emit-llvm
HB_USER_LDFLAGS=-native
Plus: It switches to call llvm-ld directly
instead of using the compiler for bin and dyn
linking.
I'm insure what to do yet. I don't have much against
new targets when it's justified, but on the other
hand the number of them is growing in a rate when
it can quickly become unmaintainable (I maintain
them, so I know). Please also take into account
that llvm-gcc isn't just meant to support Linux,
and if we start to add support to all *nix targets,
that means a lot of new files to maintain. (same
goes to clang BTW).
So:
- What is the final status with llvm linking?
why can't llvm-gcc do these tasks, when it claims
gcc compatibility?
- Is there any room to consolidate target .mk
files, or any other method to make maintenance feasible?
Finally:
- Is llvm-gcc such a _mature_ target that we should
add it to Harbour yet?
- What extra does it offer over llvm/clang?
Brgds,
Viktor
On 2009 Nov 23, at 15:57, Tamas TEVESZ wrote:
> On Mon, 23 Nov 2009, Przemysław Czerpak wrote:
>
>>> they work together correctly, if they are configured to work together
>>> correctly. my first stab, they were not. i'm much further now, and
>>> almost have a complete compilation+link cycle without workarounds like
>>> above (as i slowly start to understand how llvm + frontends work).
>>
>> So I hope that in next releases llvm-gcc will be configured to work
>> correctly with .a files created by llvm-ar. I still do not see any
>> reasons to touch Harbour.
>
> the end-user has to configure them to work together. i have to
> configure to work them together.
>
> this is how this goes:
>
> you can have llvm-gcc emit elf objects, in which case the standard elf
> binutils can work with whatever llvm-gcc emits. this is the case i
> don't care about (and this is the case that probably can be pulled off
> with just using HB_CCPREFIX).
>
> you can have llvm-gcc emit llvm bitcode, in which case the object
> format is not elf, but a blob that the rest of the *llvm* toolchain
> can work with (and consequently any *elf* toolchain can not). this is
> the case i've been massaging for the past couple of days.
>
>> And we have HB_CCPREFIX because it's standard method of using different
>> GCC based compilers in single system.
>
> *if* they use a similarly working toolchain, yes. but you can't
> separate the compiler from the toolchain anyhow, and the toolchain
> here is different enough to warrant a distinct target.
>
>> I.e. for Suse Linux we have over
>> 30 different GCC based compilers which like LLVM can be used in such way
>> and this list is systematically growing up.
>> IMHO HB_CCPREFIX is very nice solution to not introduce explicit support
>> for each of them into Harbour core code and then update them to keep such
>> builds alive. Instead using HB_CCPREFIX user can easy compile Harbour using
>> any GCC based compiler installed in his system when he need it. I still
>> do not understand why you said:
>> "HB_CCPREFIX seems absolutely not the way to go"
>> For me it's prefect solution. Of course of some configuration switches are
>> still missing to easy use different GCC based compilers using HB_CCPREFIX
>> then we should add them.
>
> again, if they use a similarly working toolchain. HB_CCPREFIX is
> perfectly ok what it is used for, but this is not that case.
>
> i am attaching a diff as to where i am at now. gcc.mk and llvmgcc.mk
> are not *that* different (much more different than gcc.mk and
> clang.mk, though), i'd be curious to see what additional knobs would
> you add to the HB_CCPREFIX stuff to merge these two, without creating
> spaghetti in gcc.mk.
>
> ifeq ($(HB_CCPREFIX),llvm-)
> CFLAGS := -emit-llvm
> else
> CFLAGS :=
> endif
>
> ? this is just as explicit support as it is with a distinct target,
> just worse, for it is "hidden" (inside another target, that is).
>
> add to that that in this case we are not in
> let-the-compiler-do-the-linking-land anymore, and it gets even more
> complicated.
>
> HB_CCPREFIX is not for this this case. (i most certainly didn't mean
> HB_CCPREFIX to be a bad way *in general*, i only meant, and still mean
> HB_CCPREFIX is a bad way *for llvm-gcc*.)
>
> now, as for the diff.
>
> i have removed leaking CFLAGS to the linker, and there is no ill
> effect i see in my build tests (the two that used to fail before that
> still fail, all the rest builds and install just as they used to).
> i'm hazarding a guess that if (big if) it affects anything, that is
> not the gnu toolchain, and it's apparently not watcom either. someone
> should do tests with msvc and borland and the rest of the gang, but i
> don't really think there will be any fallout.
>
> the rest just adds an llvmgcc target, which, at this stage compiles
> and installs mostly fine (both c and c++ modes). the only thing i'm
> missing is the libharbour{,mt}.so -> libharbour{mt}-2.0.0.so symlinks
> in the installed lib/ directory. what makes these?
>
> also, viktor, could you please add this to hbmk2? probably not in the
> tree first, but sending me (or the list) a diff to that end would be a
> big step forward.
>
> thanks,
>
> --
> [-]
>
> mkdir
> /nonexistent<llvmgcc.diff>_______________________________________________
> Harbour mailing list (attachment size limit: 40KB)
> [email protected]
> http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
