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

Node: update error & fix compile error #3751

Merged
merged 3 commits into from
Aug 17, 2017
Merged

Node: update error & fix compile error #3751

merged 3 commits into from
Aug 17, 2017

Conversation

ianchi
Copy link
Contributor

@ianchi ianchi commented Jan 4, 2017

Compile tested: ipq806x / EA8500
Run tested: ipq806x / EA8500
Description: update version and fix compile error.

@hnyman
Copy link
Contributor

hnyman commented Jan 4, 2017

@ianchi @nxhack
The node: update to v4.5.0 PR #3179 from @nxhack has been open for months and the current node maintainer @blogic has not reacted to it. One of you might need to grab the maintainership of node as you are currently interested in it.

@ianchi
Copy link
Contributor Author

ianchi commented Jan 4, 2017

I have no problem grabbing it. I also add @jow- as we were discussing this package as a possible host dependency for LuCI-NG.
I think we should go directly to v6 as it is the current LTS and v4 will enter maintenance in a few months.

@nxhack
Copy link
Contributor

nxhack commented Jan 5, 2017

@ianchi Thank you. I agree go to v6.x.

@diizzyy
Copy link
Contributor

diizzyy commented Jan 7, 2017

@ianchi
Copy link
Contributor Author

ianchi commented Jan 7, 2017

I think that both PR need to be integrated.
I'll resend it rebased on top of that.

@nxhack
Copy link
Contributor

nxhack commented Jan 10, 2017

@diizzyy
It try to new v7.x branch. but in current openwrt-packages, it need update icu package version to v58.2. So I sent PR. : #3703

This Makefile is based on @artynet edition : https://github.com/artynet/openwrt-git/tree/openwrt-1505-setup-03/package/linino/node7

@ianchi
Copy link
Contributor Author

ianchi commented Feb 27, 2017

@nxhack, your ICU package is already integrated and now node is compiling OK.
Are your planning on sending a PR for your branch, which has options for v4, v6 an v7? I think it is the most complete.
If so I'll close this PR.

My only doubt is why are you making node dependent on node/host itself? I was able to build it without this dependency
PKG_BUILD_DEPENDS:=python/host node/host

@ianchi
Copy link
Contributor Author

ianchi commented Feb 27, 2017

Another comment, ICU package is huge (11mb final ipk), I think the default option should be with no i18n.

@nxhack
Copy link
Contributor

nxhack commented Feb 27, 2017

@ianchi

My version-selectable package has following problems. Packages are not built except for selected version. Therefore, the package user can not use the desired version of the package.

The reason that "node/host" is in "PKG_BUILD_DEPENDS" is need for building v7.x.

"--with-intl" is preferably "none" by default. Because it is important that the embedded system has a small footprint.

@nxhack
Copy link
Contributor

nxhack commented Feb 27, 2017

And host-build is better "--with-intl=none".

@nxhack
Copy link
Contributor

nxhack commented Feb 27, 2017

For small footprints, it may be better to have "v4.x" too.

@ianchi
Copy link
Contributor Author

ianchi commented Feb 27, 2017

Hi @nxhack, some comments:

The reason that "node/host" is in "PKG_BUILD_DEPENDS" is need for building v7.x.
How come a package depends on itself for building?

I agree with "--with-intl" set to "none" by default.

Regarding version selection, perhaps it is best to define two variants of the package: leave "node" as the latest LTS version (v6 at this time), and add another "node_edge" (or something similar) for the latest version (v7 at this moment).

@nxhack
Copy link
Contributor

nxhack commented Feb 28, 2017

@ianchi

How come a package depends on itself for building?

Let's see : nodejs/node#9707

versions

It might be better to create a simple version selection mechanism like 'n'.
But now I think it is better to upgrade v6.x LTS in this package tree.

@nxhack
Copy link
Contributor

nxhack commented Feb 28, 2017

5353003 bytes node_v4.7.3-1_mips_24kc.ipk
6075460 bytes node-without-i18n_v6.9.5-1_mips_24kc.ipk
6100069 bytes node-with-i18n_v6.9.5-1_mips_24kc.ipk
6293501 bytes node-without-i18n_v7.5.0-1_mips_24kc.ipk
6533991 bytes node-with-i18n_v7.5.0-1_mips_24kc.ipk
12796440 bytes icu_58.2-5_mips_24kc.ipk

@ianchi
Copy link
Contributor Author

ianchi commented Feb 28, 2017

Weird issue regarding host dependency, but it is a good workaround.

Regarding versions, ICU must surely be left out of the default builds.

Having a separate package per version might be a good option, but it can't be sustained with each major version changing once a year.
Node takes a lot of time and space to compile, I'm not sure if it is really worth to have that many versions.
At most I would keep two, LTS and edge.

@nxhack
Copy link
Contributor

nxhack commented Feb 28, 2017

At most I would keep two, LTS and edge.

Roger.

And there was an update 6 days ago.
https://nodejs.org/en/download/
v6.10.0
v7.6.0

ifneq ($(findstring neon,$(CPU_SUBTYPE)),)
CONFIGURE_ARGS+= --with-arm-fpu=neon
endif

Copy link
Contributor

Choose a reason for hiding this comment

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

  1. Sorry I made mistake. it was 'CONFIG_CPU_TYPE', not 'CPU_SUBTYPE.'

  2. To prevent matching to unexpected strings, only use 'neon' and 'vfpv3'
    ('vfp' is default value)

Copy link
Member

@hauke hauke left a comment

Choose a reason for hiding this comment

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

I would suggest to only take the version 6 or 7 or even more recent and do not care about th older versions. Please also rebase this pull request.


config NODEJS_ICU
bool "enable i18n features"
default y
Copy link
Member

Choose a reason for hiding this comment

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

Please make this default to n

@ianchi ianchi force-pushed the node branch 2 times, most recently from f4bcdf0 to 9e208ee Compare June 8, 2017 05:02
@ianchi
Copy link
Contributor Author

ianchi commented Jun 8, 2017

Rebased and bumped to 6.11, which is the current LTS.
I leave an upgrade to V8.0.0 for a new PR, as it requires some workarrounds to compile (the same as v7). As explained by @nxhack

Anyway, I think we should at least finally move to v6.

@ianchi
Copy link
Contributor Author

ianchi commented Jul 12, 2017

Hi any comments on this?
This PR added to its predecessors have been waiting for over a year.
I think this should be merged soon, Node is already in V8 and switching LTS to it soon.

@champtar champtar assigned jow- and blogic and unassigned jow- Jul 15, 2017
@ianchi
Copy link
Contributor Author

ianchi commented Aug 16, 2017

Hi @blogic, any comments to merge this so to move Node to V6?

@artynet
Copy link
Contributor

artynet commented Aug 16, 2017

Hello @ianchi,

please don't hesitate to ping me if you ever need help for the node v8.x.x release series. I will test in a few hours the build for ar71xx and x86 systems.

Best, Arturo

@hnyman
Copy link
Contributor

hnyman commented Aug 16, 2017

@ianchi
blogic has not been very active regarding node packages for a while, so you should maybe add yourself as the second maintainer for the package.

@artynet
Copy link
Contributor

artynet commented Aug 16, 2017

@iachi @nxhack please take a look at my new Makefile for node v8.4.0 build :

https://github.com/artynet/LEDE/blob/linino-32/package/linino/node8/Makefile

and instead of HOST build I would suggest the download of a binary tarball as done starting from here :

https://github.com/artynet/LEDE/blob/linino-32/package/linino/node/Makefile#L57

please let me know your opinions about it. It would save a lot of build time and cpu load every time....

ianchi added 3 commits August 16, 2017 21:02
Bump version to 6.11.0
Add ICU dependency when using i18n
Tweak fpu configs

Signed-off-by: Adrian Panella <[email protected]>
Signed-off-by: Adrian Panella <[email protected]>
@ianchi
Copy link
Contributor Author

ianchi commented Aug 17, 2017

@hnyman I added myself as maintainer. (and updated minor version in the process)

@artynet, as I said before, I'd like to finally get this merged and Node updated to v6 (current LTS).
After that we can start a new PR discussing the best approach to go to v8.
Otherwise I fear we can get stuck another year in this thread.

PD: @hnyman if you are involved with Travis CI checks, please note that initially it was marked as passed even though it was failing when applying patches. (as I missed pushing a commit)

@neocturne
Copy link
Member

@artynet IMO, use of binary distributions instead of doing a host build should be avoided. In particular, it would limit the usable host platforms.

@jow-
Copy link
Contributor

jow- commented Aug 17, 2017

I agree that bootstrapping the host build from source is preferable but for local development it would be great to provide the possibility to rely on binary distribution.

Maybe a menuconfig item could be provided, possibly defaulting on CONFIG_DEVEL

@ianchi
Copy link
Contributor Author

ianchi commented Aug 17, 2017

This could be complemented with a fallback to a full host build dependency if the host machine arch is not listed in the distributed ones, so that no platform is left out. Some will simply not benefit from the performance gain.
But it should be done in a more general way as the one proposed, as here only Node's host dependency to build itself is tackled, but if other packages have host dependencies to Node, the complete host build is triggered.

Anyhow, lets please move that discussion to a new PR after we finally take the first (easier) step of merging this one to go to v6, keeping the building logic as it was.
I promise to submit it afterwards.

@jow-
Copy link
Contributor

jow- commented Aug 17, 2017

Agreed.

@jow- jow- merged commit 12cf3d7 into openwrt:master Aug 17, 2017
@ianchi ianchi deleted the node branch August 17, 2017 14:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants