AppBundlers’ main goals are to create the necessary directory structure and allow arbitrary customisation with user overrides. The bundles are relocatable to the host platform for debugging them. This goal has been achieved tremendously well. However, a minor obstacle in usability is that the user needs to finalise the bundles themselves.
Looking at all bundling cases and their finalisation steps from a distance, adding a build step for the AppBundler, which runs on the host platform, seems reasonable. Since for the building a folder with bundled objects must be created, and the building takes significantly longer than bundling, I am inclined to have a separate API for building the app.
It could work with an already present folder, created with a bundle_app, enabling quick experimentation and more advanced use cases where the user wants to clean up the direcotries of irrelevant files before building. Or it can be used as one shot as a bundle_app with the necessary argument forwarding. The exact API, though, is still unclear here as it would require automatic detection of whether the source directory points to an app project or its created bundle (perhaps a better alternative is to have build_bundle).
With this change, it seems reasonable to eliminate the .snap creation in bundle_app and delegate it to build_app instead. Zip archive creation could remain with the bundle_app as it is a reliable way to transfer data from other systems to Windows. Similarly, on Linux and MacOS, we could add the ability to form a Tar archive, which can then be transferred to host platforms.
Also app compilation with PackageCompiler could be addressed. For build_app, it could be exposed with the compile=true flag or compile=nothing|:sysimage|:pkgcache to make those operations exclusive. To enable compilation on the host system, bundle_app could create a compile.jl within the bundle, which would instantiate the manifest file containing all PackageCompiler dependencies on the host system and do the compilation there.
Some list of things which need to be done:
[ ] create build_app function and add to it a snap creation;
[ ] investigate automatic detection on deciding whether the directory is an app project or its bundle and other possible APIs;
[ ] implement macOS bundle finalisation and add .DS_Store parametrisation in bundle_app;
[ ] implement compile.jl when running bundle_app;
[ ] Figure out how system tools EditBin, SignTool and MakeAppx can be discovered reliably on Windows;
AppBundlers’ main goals are to create the necessary directory structure and allow arbitrary customisation with user overrides. The bundles are relocatable to the host platform for debugging them. This goal has been achieved tremendously well. However, a minor obstacle in usability is that the user needs to finalise the bundles themselves.
Looking at all bundling cases and their finalisation steps from a distance, adding a build step for the AppBundler, which runs on the host platform, seems reasonable. Since for the building a folder with bundled objects must be created, and the building takes significantly longer than bundling, I am inclined to have a separate API for building the app.
It could work with an already present folder, created with a
bundle_app, enabling quick experimentation and more advanced use cases where the user wants to clean up the direcotries of irrelevant files before building. Or it can be used as one shot as abundle_appwith the necessary argument forwarding. The exact API, though, is still unclear here as it would require automatic detection of whether the source directory points to an app project or its created bundle (perhaps a better alternative is to havebuild_bundle).With this change, it seems reasonable to eliminate the
.snapcreation inbundle_appand delegate it tobuild_appinstead. Zip archive creation could remain with thebundle_appas it is a reliable way to transfer data from other systems to Windows. Similarly, on Linux and MacOS, we could add the ability to form a Tar archive, which can then be transferred to host platforms.Also app compilation with PackageCompiler could be addressed. For
build_app, it could be exposed with thecompile=trueflag orcompile=nothing|:sysimage|:pkgcacheto make those operations exclusive. To enable compilation on the host system,bundle_appcould create acompile.jlwithin the bundle, which would instantiate the manifest file containing all PackageCompiler dependencies on the host system and do the compilation there.Some list of things which need to be done:
build_appfunction and add to it a snap creation;.DS_Storeparametrisation inbundle_app;compile.jlwhen runningbundle_app;EditBin,SignToolandMakeAppxcan be discovered reliably on Windows;build_appfor windows.