[LLVMdev] The Trouble with Triples

Renato Golin renato.golin at linaro.org
Wed Jul 8 11:00:59 PDT 2015


On 8 July 2015 at 17:43, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote:
> I can see a way to make the CMake option approach work nicely for native. The constructor can check for the default triple and apply the effects of the CMake options to it. I don't think there's a good way to support the multiple triples or heterogenous use cases via CMake options but support for that was more a happy coincidence rather than intentional design.

Well, I'd say the CMake options would change the behaviour for the
target architecture, not the host, which is a GCC thing, not an LLVM
thing.

Some people have suggested config files. So we'd have (say)
Targets.cfg on LLVM's source tree copied to the build tree, unless you
specify -DTARGETS_CONFIG=/foo/bar/UbuntuTargets.cfg, and that would
populate the defaults in TargetABI. Of course, this would be a big
change and it's probably for after we do all we already planned to. :)


> As far as I know there is no backwards compatibility promise, but equally it doesn't seem reasonable to give no notice before removing it. I'm therefore thinking that we can deprecate it in one release (3.7 or 3.8), then remove it in the next.

Well, the problem here is that changing build systems is even harder
than changing user code. So changes in how triples or legacy/GNU
command line options are interpreted end up being kept *a lot* longer
than other LLVM specific features.

cheers,
--renato




More information about the llvm-dev mailing list