labath added inline comments.

================
Comment at: packages/Python/lldbsuite/test/make/Makefile.rules:304
@@ +303,3 @@
+                       $(subst $(3),$(1),$(2)), \
+                       $(if $(findstring ar,$(1)), \
+                            $(if $(findstring gcc,$(3)), \
----------------
omjavaid wrote:
> labath wrote:
> > I think like we should replace ar with gcc-ar always, and not just when we 
> > don't have a version suffix present. When I have a gcc installed to a 
> > custom prefix, I get `$prefix/gcc-ar`, but not `$prefix/ar`. (Previously we 
> > would just use `ar` unconditionally, which was probably a bug.)
> > 
> > Next, when you specify a clang compiler as `clang-3.5`, you will produce 
> > `ar-3.5`, which almost certainly does not exist. I think that in case of 
> > clang we should just strip the version suffix (produce `XXX-ar`) and hope 
> > for the best (should work for all our current use cases).
> > 
> > Finally, I don't think objcopy is ever versioned with gcc (correct me if I 
> > am wrong), so I think that in case of objcopy we should strip the version 
> > suffix unconditionally `XXX-objcopy`.
> > 
> > So, to summarize, these are the transformations I think are wrong:
> > `foo/gcc` -> `foo/ar` (should be `foo/gcc-ar`)
> > `clang-3.5` -> `ar-3.5` (should be `ar`)
> > `gcc-4.8` -> `objcopy-4.8` (should be `objcopy`)
> > 
> > Let me know if these are compatible with your requirements. If we can't 
> > find a set of rules that work everywhere, we will have to abandon the magic 
> > (or maybe just leave a simple one), and require the user to specify the 
> > paths manually...
> I checked with gcc people in my team and here is what they have to say.
>  omjavaid, gcc-ar is a version of ar with LTO support
>  omjavaid, ar is just ar
>  omjavaid, likewise with gcc-nm and gcc-ranlib
>  omjavaid, ar comes from binutils, gcc-ar comes from gcc
> 
> I agree with all other points you raised except for using gcc-ar in all 
> cases. We should decide between ar (binutils) or gcc-ar (LTO support gcc 
> packaged).
> 
> Also present code doesnt generate obcopy-4.8 for me when i specify gcc-4.8. 
> If it does for you let me know.
> I agree with all other points you raised except for using gcc-ar in all 
> cases. We should decide between ar (binutils) or gcc-ar (LTO support gcc 
> packaged).
Ok, makes sense. Since we presently do not care about LTO support. I propose we 
just go with `ar` always. It will make things predictible, as we will avoid the 
whole version mess (we can just strip it). It will also mean we can treat 
`objcopy` and `ar` the same way.
I.e., the transformation rule should be:
`optional-path/optional-triple-gcc-optional.version` -> 
`optional-path/optional-triple-$TOOL`.

This will not cover all of the cases for us right now, because in case of a 
`gcc` installed to a custom prefix, there will not be an `ar` next to it, but I 
can fix that by adding a couple of symlinks.

Would that work for you?

> Also present code doesn't generate obcopy-4.8 for me when i specify gcc-4.8. 
> If it does for you let me know.
It does not add the version suffix for me either. I must have got something 
wrong yesterday. Please ignore that remark.



https://reviews.llvm.org/D20386



_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to