Re: ebeast: electron + beast
- From: Tim Janik <timj gnu org>
- To: Stefan Westerfeld <stefan space twc de>
- Cc: beast gnome org
- Subject: Re: ebeast: electron + beast
- Date: Thu, 9 Mar 2017 13:57:47 +0100
On 09.03.2017 12:52, Stefan Westerfeld wrote:
Hi!
On Wed, Mar 08, 2017 at 05:53:36PM +0100, Tim Janik wrote:
Good to see that it works for you.
I'm pondering to integrate the electron app build into the regular build
process, i.e. essentially make beast depend on npm and everything required
for electron ebeast packaging is then fetched via npm.
Well except for v8pp, that is. We'll have to maintain a patched version it seems
[1].
So I'm pondering to:
a) Possibly include a v8pp copy into beast, to spare everyone the git submodule
hassle (I don't know why git didn't opt to handle submodules *transparently*).
Do what works for you. I can live with submodule stuff, and it is not so uncommon
these days. You could check if the file ebeast/v8bse/v8pp/v8pp/module.hpp (or something)
exists in configure, and fail with a "use git submodule" message otherwise.
I just figured that it broke the other night because the v8pp repo had a
non-linear update in the for-beast branch. *And* I figured I couldn't possibly
restore last month's exact configuration that way.
Which led me to read up on git submodule and I found lots of articles about why
you shouldn't use it (due to these and other problems).
I've since managed to replace the submodule use with git subtree in my local
branch, that essentially includes a squashed copy of the v8pp repo and looks
like an ordinary merge commit. So it is completely transparent to any beast.git
user, and you only need to fiddle with the git subtree command if you want to
pull new changes from v8pp upstream or if you want to push local mods.
b) Introduce a hard dependency on npm and package ebeast via electron-packager +
several other modules that npm fetches.
Would it be much more work to make it depend on npm and build ebeast by default,
but allow disabling it with a configure switch? (like --without-ebeast)
That would allow packagers to ship just beast (without ebeast) for the timespan
that ebeast is not yet considered ready for end users.
Ah, interesting input. That shouldn't be too hard, IIRC we can simply have a
conditional make dependency for 'all: $(CONDITION) app' and similarly for the
installation.
Cu... Stefan
--
Yours sincerely,
Tim Janik
https://testbit.eu/timj/
Free software author.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]