...it doesn't actually add the --target command-line option, because I'm not entirely sure that it's the right design to have the target separate from the specification of CpuFeatures itself. Of course, there could be a check added in CpuFeatures::isa_builder to make sure we're not specifying some non-x86-64 target and things could be rearranged later, but as this is my first patch, I'm not sure what the conventions around the design here are.

Thanks!

This is a good start, and having the target distinct from CpuFeatures seems appropriate.

Shared libraries are currently created using the ld tool, that differs a lot between platforms. How are you planning to build Mach-O libraries from Linux?

Shared libraries are currently created using the ld tool, that differs a lot between platforms. How are you planning to build Mach-O libraries from Linux?

It looks like there's support for overriding what linker + flags to use already via environment variables:

so users who want to cross compile can just set the appropriate environment variables. It's not very nice, but it would work in the short term.

An alternative approach is select things based on the dynamically-determined target, not the statically-determined build platform. That's probably the right thing to do in the long term. This might wind up selecting more canonical names (ld64 for OS X targets, for instance), but I think that's OK; anybody who wants to do cross compilation probably already has the tools set up in PATH and whatnot.

As far as the tools themselves, Apple open-sources their binutils equivalents (ld64 and cctools), people have worked to make them easily compilable, and Firefox already uses those tools to cross-compile for Mac. So a lot of the hard work has already been done. :)

If a target is given, maybe we should ignore the defaults for the linker name and arguments, and print a message explaining that they have to be defined.

Otherwise, we may get a bunch of "it doesn't work!" support tickets from people setting the target without overriding the linker opts.

If a target is given, maybe we should ignore the defaults for the linker name and arguments, and print a message explaining that they have to be defined.

After thinking about it a little more, I think a better design is to have Compiler::new and company take Triples directly, rather than Option<String>, and pass the Triple around everywhere, including to link_so. The parsing into triples can be done early during command-line processing, and nobody will have to remember that None means "for the host".

New version up (not sure what the conventions are here about pushing new patches vs. force pushing); I did not require that providing --target also meant that you had to provide the environment variable, since we can infer the defaults from the targets in at least the simple cases so far.

Review ping; patch updated.