On Wed, Jun 03, 2020 at 10:59:59AM -0500, Douglas R. Reno via blfs-dev wrote:
>
> On 6/3/20 6:57 AM, Ken Moffat via blfs-dev wrote:
> > I started writing this in the ticket for node-v12.18.0 (#13628),
> > but the C++ scope errors when using system nghttp2 prompted me to go
> > with 12.18.0 for the moment. And then I discovered that the same
> > FTBFS occurred in 12.18.0, but right at the end of the build instead
> > of very early on. <sigh/>
> >
> > I'm fairly sure we have stuck to v12 at my suggestion, based on
> > https://nodejs.org/en/about/releases/ (v12 is 'active' until 20th
> > October, v14 is now 'current' i.e. development). However, python2
> > has had its last release and I keep hoping that browsers
> > (specifically firefox and falkon via qtwebengine) will eventually
> > no-longer require it. Node v12 will always require python2, but
> > python3 was added in v13 (which is now EOL) and is preferred if
> > found.
> >
> > I'm guessing that moving to v14 before October _might_ add one or
> > two extra versions compared to v12, but equally v12 gets fairly
> > frequent releases.
> >
> > For my own builds, apart from one this morning where I installed
> > v12.18.0 on one machine to check it seems to work, I'll be moving to
> > v14.4.0, partly because I hope to again try firefox (78, this time)
> > with python3 - although given the number of times my hopes have been
> > raised by the changes I've seen in ff diffs, I won't be surprised if
> > it's still not ready.
>
> Hi Ken,
>
>
> I'm sure you know by now that the new nghttp2 fixes this problem :)
>
Yes, thanks, I've caught up with Pierre's posts.
> Most of the reason why we stuck with the LTS release was due to the update
> frequency I think. I think we should stay with v12 until the next LTS comes
> out. The problem I have with Node is the amount of time it takes to build
> (and subsequently update the book). Last time I did it, it took me around 3
> hours to complete. I think it makes more sense for us to stay with an LTS
> release over a development release, especially when it comes to releasing
> the book in September.
>
For this morning's build of 12.18.0 with its included nghttp2 -
configure 0.528s
make -j4 15m58.544s
DESTDIR 18.722s
make test-only 5m23.080s
So yes, I guess that on an older machine 30 minutes is possible.
These are on the 'slow' ryzen, with gcc-10 (at the moment its my
only gcc-10 system). Yes, I do have a SATA SSD, but for a
small-size package like this I've got enough space in /tmp to use
that for the build and DESTDIR install.
> However, the potential move to python3 for Node.js is appealing too. I'm not
> sure what to say here, because I think we should stay with the LTS but it
> would be nice to get rid of another Python2 user.
>
I don't update my scripts for most of the packages until I'm doing a
fresh build - my last was in late May and we seem to have had at
least two newer v12 releases since then (a .16 point which allowed
you to reinstate system icu, and then .17). So I'm not sure that a
semi-mature development version will necessarily have many more
releases than the current stable version. But in many things I'm
often wrong (e.g. I thought everyone would go with patching png for
apng).
> Why does Mozilla insist on having node.js installed when building? It seems
> kind of odd to me that they'd use a competing JavaScript engine when they
> have their own that is built during the build process.
>
From memory, when they started to require node they began to ship an
old version (or very-old in our terms), and the required version is
still only 10.19. I think a builder needed to do something specific
to make the shipped version available. But as to *why* - I suspect
that it's another language-bootstrap case (i.e. you need the runtime to
build the source) and presumably something meant their old process
no-longer met their requirements.
But as with so much of mozilla - overall the changes are a mystery
and we outsiders are not privy to a lot of the reasoning.
ĸen
--
+++ OUT OF CHEESE ERROR. REDO FROM START +++
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
