tools: skip workaround for newer llvm#14077

nanaya · 2017-07-04T19:34:21Z

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.

refack

LGTM if CI is green

refack · 2017-07-05T03:27:51Z

common.gypi

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

refack · 2017-07-05T03:29:22Z

common.gypi

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

refack · 2017-07-05T03:32:34Z

common.gypi

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

refack · 2017-07-05T03:33:16Z

@nanaya thank you very much for your contribution 🥇

refack · 2017-07-05T03:36:17Z

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': [

Need to improve clang version detection

refack · 2017-07-05T03:39:33Z

CI: https://ci.nodejs.org/job/node-test-commit/10951/

nanaya · 2017-07-05T04:38:36Z

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 · 2017-07-05T06:52:40Z

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

Fixes: nodejs#14076 Refs: https://svnweb.freebsd.org/ports/head/www/node/Makefile?revision=444555&view=markup

nanaya · 2017-07-05T07:09:30Z

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

bnoordhuis

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 · 2017-07-05T10:47:12Z

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

refack

💯

refack · 2017-07-06T01:29:19Z

Fresh CI: https://ci.nodejs.org/job/node-test-commit/10974/

TimothyGu · 2017-07-06T02:13:45Z

common.gypi

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


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'.

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

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

nanaya · 2017-07-15T09:18:20Z

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 · 2017-07-21T19:24:07Z

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/

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]>

PR-URL: nodejs#14077Fixes: nodejs#14076 Refs: https://svnweb.freebsd.org/ports/head/www/node/Makefile?revision=444555&view=markup Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Refael Ackermann <[email protected]>

refack · 2017-07-22T14:46:45Z

Landed in fc544d4, 8979b4f

refack · 2017-07-22T14:48:46Z

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

to:

refack · 2017-07-22T18:28:13Z

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/

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]>

PR-URL: #14077Fixes: #14076 Refs: https://svnweb.freebsd.org/ports/head/www/node/Makefile?revision=444555&view=markup Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Refael Ackermann <[email protected]>

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]>

PR-URL: #14077Fixes: #14076 Refs: https://svnweb.freebsd.org/ports/head/www/node/Makefile?revision=444555&view=markup Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Refael Ackermann <[email protected]>

MylesBorins · 2017-08-16T07:51:04Z

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

MylesBorins · 2017-12-19T17:36:11Z

@refack do you think we should backport?

gibfahn · 2017-12-19T22:16:57Z

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

nodejs-github-bot added the build Issues and PRs related to build files or the CI. label Jul 4, 2017

refack previously approved these changes Jul 5, 2017
View reviewed changes

refack reviewed Jul 5, 2017
View reviewed changes

common.gypi Outdated
Copy link
Contributor
refackJul 5, 2017•
edited
Loading
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

nanaya force-pushed the freebsd-clang-4-compile branch from 34bb4a2 to fb13e57Compare July 5, 2017 06:50

tools: skip workaround for newer llvm
71dcd6e
Fixes: nodejs#14076 Refs: https://svnweb.freebsd.org/ports/head/www/node/Makefile?revision=444555&view=markup

nanaya force-pushed the freebsd-clang-4-compile branch from fb13e57 to 71dcd6eCompare July 5, 2017 06:55

nanaya changed the title ~~Don't add removed flag for freebsd 11.1+/clang 4+~~tools: skip workaround for newer llvmJul 5, 2017

bnoordhuis approved these changes Jul 5, 2017
View reviewed changes

tools: always include llvm_version in config
b2407bc
Also used in common.gypi to check whether a flag is needed or not based on llvm version.

refack approved these changes Jul 5, 2017
View reviewed changes

TimothyGu reviewed Jul 6, 2017
View reviewed changes

refack self-assigned this Jul 7, 2017

refack closed this Jul 22, 2017

addaleax mentioned this pull request Jul 24, 2017
v8.3.0 proposal #14452
Closed

addaleax mentioned this pull request Aug 2, 2017
v8.3.0 proposal #14594
Merged

MylesBorins added the lts-watch-v6.x label Aug 16, 2017

chmeeedalf mentioned this pull request Oct 17, 2017
node 8.6 assumes llvm on FreeBSD #16257
Closed

bnoordhuis mentioned this pull request Nov 30, 2017
can't build node-sass under FreeBSD 11.1 #17404
Closed

gibfahn mentioned this pull request Dec 19, 2017
build: fix bsd build with gcc #16737
Closed
2 tasks

refack removed their assignment Oct 12, 2018

Uh oh!

tools: skip workaround for newer llvm#14077

tools: skip workaround for newer llvm #14077

Uh oh!

Conversation

nanaya commented Jul 4, 2017• edited by refack Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Checklist

Affected core subsystem(s)

Uh oh!

refack left a comment

Choose a reason for hiding this comment

Uh oh!

refackJul 5, 2017

Choose a reason for hiding this comment

Uh oh!

refackJul 5, 2017

Choose a reason for hiding this comment

Uh oh!

refackJul 5, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

refack commented Jul 5, 2017

Uh oh!

refack commented Jul 5, 2017

Uh oh!

refack commented Jul 5, 2017

Uh oh!

nanaya commented Jul 5, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nanaya commented Jul 5, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

nanaya commented Jul 5, 2017

Uh oh!

bnoordhuis left a comment

Choose a reason for hiding this comment

Uh oh!

nanaya commented Jul 5, 2017

Uh oh!

refack left a comment

Choose a reason for hiding this comment

Uh oh!

refack commented Jul 6, 2017

Uh oh!

TimothyGuJul 6, 2017

Choose a reason for hiding this comment

Uh oh!

refackJul 6, 2017

Choose a reason for hiding this comment

Uh oh!

TimothyGuJul 6, 2017

Choose a reason for hiding this comment

Uh oh!

nanaya commented Jul 15, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

refack commented Jul 21, 2017

Uh oh!

refack commented Jul 22, 2017

Uh oh!

refack commented Jul 22, 2017

Uh oh!

refack commented Jul 22, 2017

Uh oh!

MylesBorins commented Aug 16, 2017

Uh oh!

MylesBorins commented Dec 19, 2017

Uh oh!

gibfahn commented Dec 19, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

nanaya commented Jul 4, 2017•
edited by refack
Loading

refackJul 5, 2017•
edited
Loading

nanaya commented Jul 5, 2017•
edited
Loading

nanaya commented Jul 5, 2017•
edited
Loading

nanaya commented Jul 15, 2017•
edited
Loading