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. _______________________________________________ beast mailing list [email protected] https://mail.gnome.org/mailman/listinfo/beast
