emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#47282: closed ([PATCH 00/13] node going forward)


From: GNU bug Tracking System
Subject: bug#47282: closed ([PATCH 00/13] node going forward)
Date: Fri, 02 Apr 2021 16:19:02 +0000

Your message dated Fri, 02 Apr 2021 18:18:08 +0200
with message-id <86ft083bjz.fsf@fsfe.org>
and subject line Re: bug#47282: [PATCH 00/13] node going forward
has caused the debbugs.gnu.org bug report #47282,
regarding [PATCH 00/13] node going forward
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
47282: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=47282
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: [PATCH 00/13] node going forward Date: Sat, 20 Mar 2021 15:57:06 +0100
So, some people seem to be interested in this one; please review and test.

Thanks again to Timothy Sample, who made quite some of these things happen.

Jelle Licht (13):
  build-system: Rewrite node build system.
  gnu: Add libuv-node
  gnu: node: Use license prefix.
  gnu: node: Add node-bootstrap.
  gnu: node: Add node-semver-bootstrap.
  gnu: node: Add node-ms-bootstrap.
  gnu: node: Add node-binary-search-bootstrap.
  gnu: node: Add node-debug-bootstrap.
  gnu: node: Add node-llparse-builder-bootstrap.
  gnu: node: Add node-llparse-frontend-bootstrap.
  gnu: node: Add node-llparse-bootstrap.
  gnu: node: Add llhttp-bootstrap.
  gnu: node: Add node-lts

 gnu/packages/libevent.scm        |  16 +
 gnu/packages/node-xyz.scm        |  74 +++--
 gnu/packages/node.scm            | 547 ++++++++++++++++++++++++++++++-
 guix/build-system/node.scm       |  39 +--
 guix/build/node-build-system.scm | 203 ++++++------
 5 files changed, 720 insertions(+), 159 deletions(-)

-- 
2.31.0




--- End Message ---
--- Begin Message --- Subject: Re: bug#47282: [PATCH 00/13] node going forward Date: Fri, 02 Apr 2021 18:18:08 +0200
Timothy,

Timothy Sample <samplet@ngyro.com> writes:

> Hi Jelle,
>
> Jelle Licht <jlicht@fsfe.org> writes:
>
>> So, some people seem to be interested in this one; please review and test.
>
> Now that I’ve finally taken the time to dig into what you’ve done here –
> I must say it’s very impressive!

If you bang your head against a wall often enough, it will crack
eventually. Head or wall, either way works in this metaphor ;-).

> I’ve taken the presumptuous step of re-rolling the series.  The reason
> is that all the “(delete 'build)” bits were bothering me.  I decided to
> have the build system check the “package.json” file for a build script
> before trying to run it.  Since that change required changing all the
> other patches, I thought it would be easier to just post the updated
> patches.  Also, I’m hoping to spare you some trouble (since you’ve
> already gone to a lot!).

Makes sense, thanks! Please be presumptuous as often as you'd like.

>
>     • Change the “Fix incorrect import semantics” comments to “Fix
>       imports for esbuild”.  To me, if TypeScript’s tsc likes the
>       imports, they are correct TypeScript (despite the esbuild bug
>       report).

"Something a native speaker of English can make sense of" != "Proper
English", and in that same vein I don't think a commmon mistake with
workaround in place is not a mistake.

I really don't care about what ends up in the codebase though, as long
as it is clear why we do what we do, which works out just fine with your
comment.

> The final result is still a little messy, but I don’t think we should
> hold this back any longer.  It’s a significant step forward, and it puts
> us in better shape to improve things incrementally.
>
> WDYT?  Let me know if I made anything worse!  :)  If the altered patches
> look good to you, I suggest you go ahead and push them.

I still adressed some of Efraim's remarks, and pushed it to master just
now.

There are quite some ways to go from here:

* Get the 'binary' importer upstreamable (I will continue with this)

* Properly support cross-compilation of Node and Node-packages

  I had a super quick look at this, but it seems that in building node,
  you build intermediate tools that run on the host. Perhaps some our
  x-compilation gurus can weigh in.

* Make a Rome-based build system, once Rome does more than linting, to
  help untangle the knot that is JavaScript-packaging

But for today (and the upcoming release), modern Node on guix \o/

Thanks folks!
 - Jelle


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]