Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tools: skip workaround for newer llvm #14077

Closed
wants to merge 2 commits into from

Conversation

nanaya
Copy link
Contributor

@nanaya nanaya commented Jul 4, 2017

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

I'm going to sleep but this seems to kind of work-ish maybe (barely compiles without this, and starts to compile with this - still running when creating this PR). Will update later if needed.

Fixes #14076.

@nodejs-github-bot nodejs-github-bot added the build Issues and PRs related to build files or the CI. label Jul 4, 2017
refack
refack previously approved these changes Jul 5, 2017
Copy link
Contributor

@refack refack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM if CI is green

common.gypi Outdated
'ldflags': [
'-Wl,--export-dynamic',
],
'conditions': [
['clang_major_version<4', {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: put spaces around the < (if it works, and AFAIK it should)

common.gypi Outdated
'ldflags': [
'-Wl,--export-dynamic',
],
'conditions': [
['clang_major_version<4', {
# Use this flag because on FreeBSD std::pairs copy constructor is non-trivial
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nits:

  1. put a . at the end of the two sentences
  2. put them one after the other
  3. put the URL last and start the line with Ref: https://...

common.gypi Outdated
@@ -65,6 +65,9 @@
}, {
'clang%': 0,
}],
['OS=="freebsd"', {
'clang_major_version': '<!(echo "__clang_major__" | cc -E -P -)',
Copy link
Contributor

@refack refack Jul 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a chance that cc will be gcc? see my other comment

@refack
Copy link
Contributor

refack commented Jul 5, 2017

@nanaya thank you very much for your contribution 🥇

@refack
Copy link
Contributor

refack commented Jul 5, 2017

ignores clang on other platforms
assumes compiler is cc
assumes cc is clang
shell script

You could try and deduce if clang is used and which version it is in ./configure which is the script that creates config.gypi. Then you'll just need the 'conditions': [

@refack refack dismissed their stale review July 5, 2017 03:37

Need to improve clang version detection

@refack
Copy link
Contributor

refack commented Jul 5, 2017

@nanaya
Copy link
Contributor Author

nanaya commented Jul 5, 2017

I noticed some weird thing here. The original goal was to allow building node-sass. @bnoordhuis suggested using llvm_version variable which is in generated config.gypi. It is indeed usable when building node.

But it doesn't seem to be used when building node-sass. The variable is in bundled config.gypi from here which is unpacked to ~/.node-gyp. I also tried modifying FreeBSD package's config.gypi (which somehow doesn't have llvm_version declared even though I'm pretty sure it's built with clang/llvm) but it's not read either.

(the above is using node from package)

Using llvm_version from config.gypi when building node does indeed work but it doesn't help much if it breaks building modules.

I'll report back later.

@nanaya nanaya force-pushed the freebsd-clang-4-compile branch from 34bb4a2 to fb13e57 Compare July 5, 2017 06:50
@nanaya
Copy link
Contributor Author

nanaya commented Jul 5, 2017

Using llvm_version seems fine so I updated it accordingly. I have no idea why it's not there when trying it before.

@nanaya nanaya force-pushed the freebsd-clang-4-compile branch from fb13e57 to 71dcd6e Compare July 5, 2017 06:55
@nanaya
Copy link
Contributor Author

nanaya commented Jul 5, 2017

Looks like FreeBSD's packaged node doesn't have llvm_version defined in process.config for some reason.

@nanaya nanaya changed the title Don't add removed flag for freebsd 11.1+/clang 4+ tools: skip workaround for newer llvm Jul 5, 2017
Copy link
Member

@bnoordhuis bnoordhuis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks. CI: https://ci.nodejs.org/job/node-test-pull-request/8986/

If using llvm_version is an issue for freebsd-ports, I'm okay with using your previous approach of shelling out but can you add an explaining comment in common.gypi in that case?

Also used in common.gypi to check whether a flag is needed or not
based on llvm version.
@nanaya
Copy link
Contributor Author

nanaya commented Jul 5, 2017

FreeBSD ports disables bundled openssl by default and thus llvm_version is not assigned. I moved the assignment outside so it should be fine.

Copy link
Contributor

@refack refack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💯

@refack
Copy link
Contributor

refack commented Jul 6, 2017

# https://lists.freebsd.org/pipermail/freebsd-toolchain/2016-March/002094.html
'cflags': [ '-D_LIBCPP_TRIVIAL_PAIR_COPY_CTOR=1' ],
'conditions': [
['llvm_version < "4.0"', {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this check future proof? Not sure how the < operator operates, but what happens if llvm_version == "10.0"? If it is a string comparison, '10.0' < '4.0'.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good quastion, but in that case get_llvm_version would fail since it uses this RegEx r"(^(?:FreeBSD )?clang version|based on LLVM) ([3-9]\.[0-9]+)")
https://github.com/nodejs/node/blob/master/configure#L585

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, in that case don't worry about it. We'll have to update everything anyway when 10.0 comes.

@refack refack self-assigned this Jul 7, 2017
@nanaya
Copy link
Contributor Author

nanaya commented Jul 15, 2017

I think this should be fine. Just tell me if there's anything else I need to do (rebase, commit message, code style, etc).

Updating llvm_version check to be more accurate would need a rework on its structure. Perhaps splitting it into llvm_version_major and llvm_version_minor or having some kind of version comparison function.

I also see deps/openssl/openssl.gypi is currently comparing llvm_version in similar way I did here.

@refack
Copy link
Contributor

refack commented Jul 21, 2017

I think this should be fine. Just tell me if there's anything else I need to do (rebase, commit message, code style, etc).

@nanaya thanks, this looks good as is.
CI: https://ci.nodejs.org/job/node-test-pull-request/9290/

refack pushed a commit to refack/node that referenced this pull request Jul 22, 2017
Also used in common.gypi to check whether a flag is needed or not
based on llvm version.

PR-URL: nodejs#14077
Reviewed-By: Ben Noordhuis <[email protected]>
Reviewed-By: Refael Ackermann <[email protected]>
refack pushed a commit to refack/node that referenced this pull request Jul 22, 2017
@refack
Copy link
Contributor

refack commented Jul 22, 2017

Landed in fc544d4, 8979b4f

@refack refack closed this Jul 22, 2017
@refack
Copy link
Contributor

refack commented Jul 22, 2017

@nanaya thank you for your contribution 🥇 and congrats on being promoted by GitHub from:
image
to:
image

@refack
Copy link
Contributor

refack commented Jul 22, 2017

P.S. @nanaya for your next PR, if you want your full name to appear in the commit logs you could follow https://help.github.com/articles/setting-your-username-in-git/

addaleax pushed a commit that referenced this pull request Jul 22, 2017
Also used in common.gypi to check whether a flag is needed or not
based on llvm version.

PR-URL: #14077
Reviewed-By: Ben Noordhuis <[email protected]>
Reviewed-By: Refael Ackermann <[email protected]>
addaleax pushed a commit that referenced this pull request Jul 22, 2017
Fishrock123 pushed a commit that referenced this pull request Jul 24, 2017
Also used in common.gypi to check whether a flag is needed or not
based on llvm version.

PR-URL: #14077
Reviewed-By: Ben Noordhuis <[email protected]>
Reviewed-By: Refael Ackermann <[email protected]>
Fishrock123 pushed a commit that referenced this pull request Jul 24, 2017
@addaleax addaleax mentioned this pull request Jul 24, 2017
@addaleax addaleax mentioned this pull request Aug 2, 2017
@MylesBorins
Copy link
Contributor

Should this land on v6.x?
8979b4f would need to be manually backported fwiw

@MylesBorins
Copy link
Contributor

@refack do you think we should backport?

@gibfahn gibfahn mentioned this pull request Dec 19, 2017
2 tasks
@gibfahn
Copy link
Member

gibfahn commented Dec 19, 2017

Should come with #16737 if it lands on 6.x

@refack refack removed their assignment Oct 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build Issues and PRs related to build files or the CI.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Can't build stuff (using gyp) on FreeBSD 11.1 (or clang 4.0)
7 participants