Chakracore: Inconsistent download archives across platforms

[mathiasbynens]

The download archives have an inconsistent structure on different platforms.

1. The macOS and Linux archives contain a ChakraCoreFiles folder which contains everything, including the LICENSE file.

2. The Windows archives, however, don’t contain this parent ChakraCoreFiles folder, and instead have all the files at the root of the archive. They also don’t include the LICENSE file.

cc @obastemur

[obastemur]

Agree with @mathiasbynens and I believe we need to change couple of things with Windows bundles.

• put the samples and LICENSE (similar to xplat package)

@dilijev @MSLaguana what do you think?

[dilijev]

• Yes, all packages across all platforms should look the same.
• I don't think the archive should have single folder at the root of the archive, as it is redundant. Edited: After discussing, I now think it's better to have this redundant folder (in all downloads for consistency) than to risk polluting CWD when extracting an archive.
• We should include the LICENSE in all archives.
• Not sure we need to include the Samples in any of them, as those are present in the wiki and represent clutter in the packages themselves. Maybe we could include a release-specific README with links to samples, description of how to use the package and so on.

[liminzhu]

Agree with @dilijev . The Windows package also lacks the headers and .lib file, which are necessary for embedding.

[MSLaguana]

The single folder at the root of the .tar.gz is pretty common, so you don't unzip something and find that you've polluted the current directory unexpectedly. Typically that folder name matches the name of the archive (without extension) but that's just a convention.

On windows, we have top-level folders for each flavor, while on xplat we only build one flavor. If we want a consistent folder structure between windows and xplat, what would we like it to be?

- cc_<platform>_<version>
\ - LICENSE
  - bin
  \ - <platform>
    \ - ch[.exe]
      - chakracore.[dll / so]
      - chakracore.lib?
  - include
  \ - <various headers>

[MSLaguana]

Spoke with @dilijev a bit and realised that the linux packages are also missing the libchakracore.a files. We might want to re-visit what the purpose of these released archives is, and make sure that they are fit for purpose.

E.g. are they intended for just running ch.exe foo.js and getting output? Are they intended to allow you to embed chakracore, and so we should provide the .lib/.a files?

[mathiasbynens]

I assumed the use case was to just run ch.exe foo.js, because embedders would probably want to check out the source code.

[dilijev]

I yield to the argument in favor of a single folder at the root of an archive. I suggested removing it because most archival tools on Windows will offer to (or by default) extract to a directory with the same name as the archive. However, polluting your CWD with whatever was in the archive is worse than a redundant subdir.

On xplat builds where we ship only x64, the x64/ subdir would look redundant but it seems like a good thing to keep things as congruent as possible between the various platforms' packages.

[dilijev]

Windows packages are not currently suited to embedding ChakraCore.dll in an application because they are missing the dev headers. Not sure about the *nix packages. If we decide to remove support for embedding it wouldn't be a regression from the perspective of Windows packages. (Also there's the NuGet packages for that.)

I am unsure about whether I think these downloads should enable embedding ChakraCore...

[obastemur]

Spoke with @dilijev a bit and realised that the linux packages are also missing the libchakracore.a files. We might want to re-visit what the purpose of these released archives is, and make sure that they are fit for purpose.

We had discussed this initially (offline) hence I don't think we have any reference on Github. Let me try to explain;

We do not miss archive files. Xplat package ensures an easy experience with ChakraCore targeting multiple distros with a single binary.

There are multiple reason for not including archive files with xplat packages. Couple of them;

• Archive files are more platform dependent and used for static embedding on xplat. Our linux package targets multiple distros.
• Are we going to ship the archive files for ICU too?
• How about stdlib?

The list goes on with the package size etc.

If a project wants to embed ChakraCore statically, well, we have enough samples are explaining the usage.

my 2 cents;; unless there is a good reason, I'm -1 on putting the platform dependent archive file into xplat packages and raising confusions.

[dilijev]

@obastemur That's totally fair. In that case I think we should say across the board that the purpose of these archives is not to be consumed by embedders, but rather ONLY to provide a runnable host from a given release (ch).

[dilijev]

Oh I think I misunderstood... Static archives (.a/.lib files) should not be included because they are too system-specific and large. However, shared object files for embedding ChakraCore (by .so/.dll) should be provided in these packages, in addition to the runnable host.

Therefore, across the board these packages should provide a runnable host and the tools necessary to dynamically link ChakraCore in an application.

[obastemur]

@liminzhu ping? @digitalinfinity any comment?

[liminzhu]

I can get behind @dilijev 's last comment and say the package is primarily for running ch. I always liked the idea of having a separate dev package though but that's perhaps a QoL thing we can do after we hear enough feedback.

[dilijev]

@liminzhu in terms of dev-focused packages we have the NuGet packages (which are windows-specific atm, and not sure if there's any way to make them xplat).

It is probably possible to add a linux and/or osx dev-specific package, like an apt-get feed to install chakracore dev tools for some specific OSes like Ubuntu, but that's potentially a lot of work to maintain and/or would inherently show bias towards certain platforms as a matter of what we can actually maintain.

I believe we discussed this before (can't find the issue at the moment) and decided against it unless we see a definite need.

We don't have good visibility on how folks who consume ChakraCore actually consume or embed it. I think we assume that most people build from source rather than using tools from and of our officially published packages. For Windows, we know that some folks use or would like to use the NuGet packages. For Linux and OSX I'm not sure we really know.

The runnable host is helpful for cross engine testing via tools like eshost-cli (eshost) and jsvu and individual curiosity about the capabilities of ChakraCore at a particular release, and beyond that I'm not sure.

[yufeih]

We don't have good visibility on how folks who consume ChakraCore actually consume or embed it.

@dilijev , in docfx we embed ChakraCore in a dotnet core app. Our target platform includes Windows, MacOS and linux. The current NuGet approach of embedding only works for Windows, so we have to fallback to other solutions on other platforms.