xcode portgroup only recognizes Xcode compilers

[ryandesign (Ryan Carsten Schmidt)]

The xcode portgroup needs to be enhanced to support compilers provided by MacPorts so that non-working compilers can be blacklisted meaningfully.

[cooljeanius (Eric Gallager)]

Replying to ryandesign@…:

The xcode portgroup needs to be enhanced to support compilers provided by MacPorts so that non-working compilers can be blacklisted meaningfully.

I think this is more of an issue with Xcode itself than it is with the Xcode portgroup... People have said they've had to make special Xcode plugins to get it to use MacPorts-provided compilers:

​http://www.implbits.com/About/Blog/tabid/78/post/building-with-gcc-4-6-on-osx/Default.aspx

​http://skurganov.blogspot.com/2010/10/integrating-gcc-44-to-xcode-macossnow.html

[cooljeanius (Eric Gallager)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

If we need to write Xcode plugins (which appear to just be folder-bundles with a plist inside) to get Xcode to understand MacPorts compilers, we can have each compiler port do that, but there are some questions:

• Can we tell Xcode to look in a particular directory for plugins (e.g. somewhere under ${prefix}) or must it be a particular directory (e.g. in /Library/Application Support)?
• Is this directory the same for all versions of Xcode that MacPorts supports — Xcode 2 on Tiger through Xcode 5 on Mavericks and beyond?
• Can we write a single plugin that works in all versions of Xcode or do different Xcode versions need different plugins?

[cooljeanius (Eric Gallager)]

Replying to ryandesign@…:

If we need to write Xcode plugins (which appear to just be folder-bundles with a plist inside) to get Xcode to understand MacPorts compilers, we can have each compiler port do that

I'd recommend making the Xcode plugins be subports of each compiler port, so that way people who don't want to or can't use the plugin with Xcode can avoid it.

• Can we tell Xcode to look in a particular directory for plugins (e.g. somewhere under ${prefix}) or must it be a particular directory (e.g. in /Library/Application Support)?
• Is this directory the same for all versions of Xcode that MacPorts supports — Xcode 2 on Tiger through Xcode 5 on Mavericks and beyond?
• Can we write a single plugin that works in all versions of Xcode or do different Xcode versions need different plugins?

There are many different directories that plugins can be found in, and some of them are compatible between Xcode versions, while others aren't. I think if we use the ${developer_dir} variable we should be good though, because that already varies between different versions, and I'm pretty sure it does it correctly.

[ryandesign (Ryan Carsten Schmidt)]

Replying to egall@…:

Replying to ryandesign@…:

If we need to write Xcode plugins (which appear to just be folder-bundles with a plist inside) to get Xcode to understand MacPorts compilers, we can have each compiler port do that

I'd recommend making the Xcode plugins be subports of each compiler port, so that way people who don't want to or can't use the plugin with Xcode can avoid it.

That would be ok, so long as MacPorts base can automatically add a build dependency on said subport when needed. Otherwise it will be too onerous on port maintainers.

[ryandesign (Ryan Carsten Schmidt)]

Replying to egall@…:

There are many different directories that plugins can be found in, and some of them are compatible between Xcode versions, while others aren't. I think if we use the ${developer_dir} variable we should be good though, because that already varies between different versions, and I'm pretty sure it does it correctly.

${developer_dir} can vary within a single OS X version, so binary packages could not be shared. Since it's just small text files we could disable fetching of archives for these plugin subports.

[mascguy (Christopher Nielsen)]

Add keyword portgroup, to pg-related tickets