FreeBSD: Search for newest clang compatible candidate

[GuillaumeBibaut]

Seach for newest clang compatible candidate, and make this FreeBSD clang packages compatible.

[gribozavr]

I'd prefer we keep using un-suffixed version if it is present, checking for it first, even if it is not the newest version. This respects system-wide choices made by the /etc/alternatives system, as well as per-user overrides based on $PATH.

[GuillaumeBibaut]

/etc/alternatives seems to be some linuxism, it is not supported at all on FreeBSD (it's not in the base system). Clang base system version on a FreeBSD 10.2-RELEASE is 3.4.1. So, user has to install a clang package >= 3.5 in order to be compatible with what's defined in this shell script. For example, clang 3.5 package would install /usr/local/bin/clang35, /usr/local/bin/clang++35 etc. I didn't know about that alternatives system on Linux, I'm only using FreeBSD.

[gribozavr]

/etc/alternatives seems to be some linuxism

Yes, it is.

So, user has to install a clang package >= 3.5 in order to be compatible with what's defined in this shell script.

Right, that was the intent.

On FreeBSD, when would one get the un-suffixed 'clang' binary? And which version of Clang would it be on a recent system?

[GuillaumeBibaut]

the un-suffixed clang binary is only install with the base binaries installation, so whenever one is installing FreeBSD >= 9.1-RELEASE.
Each release brings newer pulls of clang, for 9.3-RELEASE and 10-STABLE it is 3.4.1.
I think that for the next major release: 11.0-RELEASE, which is supposed to land after september 2016, the clang installed in the base system would be 3.7... at least it is for now in 11-CURRENT snapshots.

[gribozavr]

3.4.1 is old, I agree.

Since 11-CURRENT will ship with a new Clang, I'd prefer special casing older FreeBSD systems, pinning a specific version of Clang known to work there, while defaulting to the system compiler from the base installation in the general case. @GuillaumeBibaut, what do you think?

[GuillaumeBibaut]

Sure I understand about the general case. Would setting the HOST_CC and HOST_CXX variable before starting the build script be enough ? It doesn't feel really automatic, but it could be documented.

[gribozavr]

The convention is to set the CC and CXX variables if we were to support it. I'm concerned that this would cause us to give people working on different systems different build advice, which would create barriers for contributing. build-script should just do the right thing for every system that we support.

[GuillaumeBibaut]

Sorry for the latency.

I understand such barriers, but actually FreeBSD gets those barriers more than any other already supported OS for Swift build. I don't really know how to "pin" a specific version of clang in this script, or at least I don't understand what you've meant here. I'd really like to help contribute, but I don't really get what the solution could be.

What I can tell you is that I'm trying to build Swift as a normal user on a FreeBSD 10.2-RELEASE where clang 3.4.1 is already installed in /usr/bin/clang and /usr/bin/clang++.
To install newer version of clang, one has to install a port or package of clang, which would be installed in, for example for clang 3.5, /usr/local/bin/clang35 and /usr/local/bin/clang++35. The PATH env var is set so that /usr/bin/* is favor'd to /usr/local/bin/. (...:/usr/bin:...:/usr/local/bin:...).

I'd really like to come to a solution for this, but I don't really know how to make it. :)

[gribozavr]

I understand that. When I said "pin" I meant check for OS version, and if it is a specific one (say, FreeBSD 10.*), then use "clang3x" binary, as appropriate for that system, skipping the automatic detection. Does this sound reasonable?

[GuillaumeBibaut]

I guess it is reasonable, I'll try to send in a new patch.

[GuillaumeBibaut]

I just hope that would be good enough :) I've also tried to merge the master in my branch to be sure it can be merged.

[gribozavr]

@GuillaumeBibaut The differences tab shows other changes in addition to build-script changes... I'm not sure that's intended. May I ask you git push -f one squashed commit to your branch? The change itself LGTM.

[GuillaumeBibaut]

well ... I'm trying to follow some howto to rebase and squash commit, but it seems it has only add more files.

[GuillaumeBibaut]

Should I close this pull request and create a new one with just my patch ?

[iamanushil]

Yeah do it and please tell me how and from where to learn language and
github plzz
On 11-Dec-2015 12:28 PM, "Guillaume Bibaut" [email protected]
wrote:

Should I close this pull request and create a new one with just my patch ?

—
Reply to this email directly or view it on GitHub
#169 (comment).

[GuillaumeBibaut]

I had to reset to my git clone command and apply back the changes for FreeBSD support of clang. Let's hope it's ok now.

[gribozavr]

Thank you, merging!