nightingale-media-player / nightingale-hacking

Working tree for the community fork of Songbird, Nightingale. If building, use the sb-trunk-oldxul (development) branch, with the tag 1.12.1 tag for stable, for now. The master-xul-9.0.1 branch is the current progress in building Nightingale with XULRunner 9 and builds, but is broken. All help in terms of patches and pull requests is welcome.
https://getnightingale.com
GNU General Public License v2.0
185 stars 41 forks source link

On incremental builds, don't reextract xulrunner archive #256

Open johnmurrayvi opened 10 years ago

johnmurrayvi commented 10 years ago

Throwing out an idea here.. I've noticed that a significant amount of build time (for me at least) is spent on extracting the xulrunner archive into compiled/dist/xulrunner, particularly for the debug builds. It would seem somewhat sensible to not extract every build, especially once an initial clean compilation has been finished. The most obvious solution I can think of would be to just check if the compiled/dist/xulrunner directory exists, since it's very unlikely that the or its contents would be modified or deleted after the initial build, except for a "make clean".

Any thoughts, ideas, or problems that would make this a bad idea?

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/1386837-on-incremental-builds-don-t-reextract-xulrunner-archive?utm_campaign=plugin&utm_content=tracker%2F230233&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F230233&utm_medium=issues&utm_source=github).
rsjtdrjgfuzkfg commented 10 years ago

I agree. However, with build.sh this will not work as expected, as we clean on each build currently. Maybe we should also change that?

johnmurrayvi commented 10 years ago

That's true... I was thinking it could be implemented as a make rule. Is it really necessary to recompile everything in build.sh for every build? What if there's a conditional that if a new deps or vendor archive is downloaded, then clobber the compile dir?

freaktechnik commented 10 years ago

I think we should make getting dependencies their own step, needed for building. So factoring them out into their own script and maybe enhance them with automatically downloading debug deps, if --enable-debug is set... If people want to use build.sh to build (which will do everything if you just want to build nightingale in a fresh clone of the repo), they can. To make an incremental build instead, you'll only have to do make clobber && make (which you're already able to, btw)

rsjtdrjgfuzkfg commented 10 years ago

@freaktechnik: you should be able to just use make, without clobber imho (which should be quite a lot faster).

freaktechnik commented 10 years ago

@rsjtdrjgfuzkfg actually, that works for me.

freaktechnik commented 10 years ago

I've tried it (it's in the dependencies/Makefile.in), however this would need more than just a check if extraction is needed, as the XULRunner stub (nightingale-bin or nightingale.exe) gets moved out of the xulrunner dir each time.

johnmurrayvi commented 10 years ago

That's what I ran into when I briefly tried it. I don't know why I didn't think of this then, but what about just changing the move to a copy?

freaktechnik commented 10 years ago

Because dist should be as stripped as possible? Best would probably be to add a variable like INSTALL_XULRUNNER, which is then used to determine all the actions regarding correctly installing XULR to the dir. But I'd have to read further into the makefile in order to find out what exactly would make the most sense.

johnmurrayvi commented 10 years ago

Yeah that's true. I had figured the extra one could be pruned out before a release, but that's a bad solution. I'm going to ping you on IRC

freaktechnik commented 10 years ago

So wie could stage XULR in compiled, however that adds copying all XULR files to dist.

johnmurrayvi commented 10 years ago

Yeah, the initial build would take longer, but subsequent ones would be much faster... Anybody have any thoughts, opinions or opposition to this?