You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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;
Implement Windows build_app for windows.
The text was updated successfully, but these errors were encountered:
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_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 havebuild_bundle
).With this change, it seems reasonable to eliminate the
.snap
creation inbundle_app
and delegate it tobuild_app
instead. Zip archive creation could remain with thebundle_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 thecompile=true
flag orcompile=nothing|:sysimage|:pkgcache
to make those operations exclusive. To enable compilation on the host system,bundle_app
could create acompile.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:
build_app
function and add to it a snap creation;.DS_Store
parametrisation inbundle_app
;compile.jl
when runningbundle_app
;EditBin
,SignTool
andMakeAppx
can be discovered reliably on Windows;build_app
for windows.The text was updated successfully, but these errors were encountered: