[emscripten] Make the satisfying of requirements more friendly

[sergz]

Background

This issue is a continuation of ​https://codereview.adblockplus.org/29527808/.

Currently the preparing of the environment contains some hurdles, in particular:

• [emscripten] the installation can be just nontrivial depending on a platform and version, in addition it creates some files in a user home directory.
• [meson] one has to create yet one virtual environment for adblockpluscore-emscripten on each development machine (linux, osx, windows) in order to have there meson, keep the exact version of meson there because the recent one can be broken and of course "activate" that virtualenv configuration in a shell. In addition we are using python2 but meson requires python3. We have not modified meson's code yet but chances for that are big enough. We usually keep a copy of third party projects for resilience if it's possible. It's inconsistent with having gyp, V8, gtest and a list of packages in package.json, imagine that instead we had npm packages in a list in the readme file.
• [ninja] one has to download ninja executable and put a path to it into PATH environment variable because meson requires it to be available.

Proposals

• [emscripten] requires a research
• [meson] We could have it in our dependencies file checked out into third_party/meson and accessed from a special script. A user will not have to care about the version of meson, fiddle with virtualenv, etc. It's just here out of the box.
• [ninja] It could be automatically downloaded into third_party/ninja/ from our artifact server and the script, mentioned in the previous item, could be aware about it. So, no preparation steps from a user again. The everything just works.

[trev]

I recently reinstalled Emscripten on Linux and this task got a lot simpler - there are now binaries available for 1.37.3 as well as subsequent versions, so now it's only a matter of downloading a large chunk of data.

Meson doesn't normally require a virtual environment - it's merely a build tool that should be installed globally. The only complication here is us requiring a specific version of it, which is bogus IMHO. Just because there is one bug (not even affecting all Windows users judging by your description) doesn't mean that we need to require a specific version. We should merely make sure that this bug is fixed - and it seems that it will be fixed soon, now that you notified the developers.

Note that we generally don't keep our own copy of build tools - not gcc, not CMake, and certainly not Visual Studio. gyp is a special case because we cannot really use it "as is." We have to wrap and monkey-patch it in order for gyp to become usable on Windows. And the vendor won't fix these issues (or anything, it has de facto already been unmaintained when we started using it).

Finally, I'm not convinced that installing ninja ourselves instead of letting the user do it is such a great idea. On Ubuntu, one will run apt install ninja-build and have that tool available globally for any projects that need it. Besides, are you certain that meson requires ninja to be added to PATH? From what I can tell, it's merely something for you to call ninja more conveniently - you could just as well invoke it with a full path instead.

Are you overthinking this maybe? What's the issue you are trying to solve? If this is about making it things easier for people working only on adblockpluschrome for example, then maybe committing lib/compiled.js to the repository is an easier solution than requiring people to build it themselves every time.

[sergz]

Replying to trev:

I recently reinstalled Emscripten on Linux and this task got a lot simpler - there are now binaries available for 1.37.3 as well as subsequent versions, so now it's only a matter of downloading a large chunk of data.

it's a good news.

Meson doesn't normally require a virtual environment - it's merely a build tool that should be installed globally. ...

On Ubuntu, one will run apt install ninja-build and have that tool available globally...
Are you overthinking this maybe? ...

Maybe you are right, I'm just not installing such packages globally on my machines.

BTW, it's not so easy (if it's still even possible) to download old Visual Studio, so keeping a full setup package internally is not a bad idea.

[hfiguiere]

I'm fine reverting to 0.40.0+ as requirement for meson.

[hfiguiere]

I believe that meson and ninja should be handled by the OS package management, like the compilers. On macOS, Homebrew is fine, on Linux, whichever is available in the distro. (I don't know for Windows though)

[sebastian]

Sorry, but we switched to GitLab. If this issue is still relevant, please file it again in the ​new issue tracker.