From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: "Ignacy Gawędzki" <ignacy.gawedzki@green-communications.fr>
Cc: buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH v3] package/chartjs: bump to version 3.9.1
Date: Mon, 19 Sep 2022 11:46:17 +0200 [thread overview]
Message-ID: <20220919114617.67d80b53@windsurf> (raw)
In-Reply-To: <20220919091607.a3n36rn44ct3iwuq@zenon.in.qult.net>
Hello Ignacy,
On Mon, 19 Sep 2022 11:16:07 +0200
Ignacy Gawędzki <ignacy.gawedzki@green-communications.fr> wrote:
> Yes, this downloads and builds additional stuff. I'm about to send a
> v4 with a package-lock.json file which makes the dependencies stick to
> precise versions, in order to make the builds reproducible (the
> package-lock.json file is locally generated, since it is not provided
> upstream).
>
> There are already ongoing discussions about the way several new javascript
> packages (forge, openlayers, vue.js) are to be built. Since
> retrieving ready-to-use files from registry.npmjs.org is not an
> option, these have to be built using host-nodejs.
>
> For me, both ways do the job, please tell me which one to use and I'll
> be happy with it.
We discussed this package (and another JS library with the same issue)
during the Buildroot Developers Meeting this week-end.
The consensus is that for now we prefer to continue using the
pre-generated JS files. Indeed, building host-nodejs is super long, and
very annoying just to get a small JS library built.
Longer term, what we would like is:
- Be able to use a pre-compiled NodeJS for the host instead of
building our own host-nodejs. This is what we already do for Rust.
- Implement vendoring support for NodeJS packages, like we have done
for Go and Rust. Vendoring support means that the "npm install" part
that downloads the dependencies would be done during the download
step, and all dependencies would be integrated inside the package
tarball in DL_DIR.
So for your next revision of the patch, you can switch back to using
the pre-generated JS files. Then if you are brave and want to give a
try at implementing the two points mentioned above, it would be amazing!
Thanks a lot!
Thomas
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2022-09-19 9:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-13 9:32 [Buildroot] [PATCH v3] package/chartjs: bump to version 3.9.1 Ignacy Gawędzki
2022-09-17 13:17 ` Thomas Petazzoni
2022-09-19 9:16 ` Ignacy Gawędzki
2022-09-19 9:46 ` Thomas Petazzoni via buildroot [this message]
2022-09-22 13:34 ` Ignacy Gawędzki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220919114617.67d80b53@windsurf \
--to=buildroot@buildroot.org \
--cc=ignacy.gawedzki@green-communications.fr \
--cc=thomas.petazzoni@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox