| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM if CI is green
Sorry, something went wrong.
There was a problem hiding this comment.
Nit: put spaces around the < (if it works, and AFAIK it should)
Sorry, something went wrong.
There was a problem hiding this comment.
nits:
Sorry, something went wrong.
There was a problem hiding this comment.
Is there a chance that cc will be gcc? see my other comment
Sorry, something went wrong.
|
@nanaya thank you very much for your contribution 🥇 |
Sorry, something went wrong.
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': [ |
Sorry, something went wrong.
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
|
Using llvm_version seems fine so I updated it accordingly. I have no idea why it's not there when trying it before. |
Sorry, something went wrong.
|
Looks like FreeBSD's packaged node doesn't have llvm_version defined in process.config for some reason. |
Sorry, something went wrong.
There was a problem hiding this comment.
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?
Sorry, something went wrong.
Also used in common.gypi to check whether a flag is needed or not based on llvm version.
|
FreeBSD ports disables bundled openssl by default and thus llvm_version is not assigned. I moved the assignment outside so it should be fine. |
Sorry, something went wrong.
There was a problem hiding this comment.
💯
Sorry, something went wrong.
Sorry, something went wrong.
| # https://lists.freebsd.org/pipermail/freebsd-toolchain/2016-March/002094.html | ||
| 'cflags': [ '-D_LIBCPP_TRIVIAL_PAIR_COPY_CTOR=1' ], | ||
| 'conditions': [ | ||
| ['llvm_version < "4.0"', { |
There was a problem hiding this comment.
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'.
Sorry, something went wrong.
There was a problem hiding this comment.
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
Sorry, something went wrong.
There was a problem hiding this comment.
Ah, in that case don't worry about it. We'll have to update everything anyway when 10.0 comes.
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
@nanaya thanks, this looks good as is. |
Sorry, something went wrong.
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 <info@bnoordhuis.nl> Reviewed-By: Refael Ackermann <refack@gmail.com>
PR-URL: nodejs#14077 Fixes: nodejs#14076 Refs: https://svnweb.freebsd.org/ports/head/www/node/Makefile?revision=444555&view=markup Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Refael Ackermann <refack@gmail.com>
Sorry, something went wrong.
|
@nanaya thank you for your contribution 🥇 and congrats on being promoted by GitHub from: |
Sorry, something went wrong.
|
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/ |
Sorry, something went wrong.
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 <info@bnoordhuis.nl> Reviewed-By: Refael Ackermann <refack@gmail.com>
PR-URL: #14077 Fixes: #14076 Refs: https://svnweb.freebsd.org/ports/head/www/node/Makefile?revision=444555&view=markup Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Refael Ackermann <refack@gmail.com>
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 <info@bnoordhuis.nl> Reviewed-By: Refael Ackermann <refack@gmail.com>
PR-URL: #14077 Fixes: #14076 Refs: https://svnweb.freebsd.org/ports/head/www/node/Makefile?revision=444555&view=markup Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: Refael Ackermann <refack@gmail.com>
|
Should this land on v6.x? |
Sorry, something went wrong.
|
@refack do you think we should backport? |
Sorry, something went wrong.
|
Should come with #16737 if it lands on 6.x |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Checklist
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.