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
Using aliBuild in a shared environment would currently require every software developer to provide a full copy of the whole sw/ folder. This means that in our use case it takes up 10GB of disk quota for packages that could be shared. --remote-store already saves the compilation time for these shared packages, but does not remove the disk space requirement.
Doing this would simply require setting symbolic links to the shared $PACKAGE_ROOT directories. If combined with atomic builds and a flag (--prefer shared) to always take non-dev-mode packages from the shared location, if possible, it would provide a safe and stable development environment.
The text was updated successfully, but these errors were encountered:
Yes agreed. Supporting environment from modules as we do support brew on mac is one of the things which we would like to add, however it's a bit tricky because we need a sort of database of all the hashes for the packages in sw, so that we can do the matching with the local hashes.
Using aliBuild in a shared environment would currently require every software developer to provide a full copy of the whole sw/ folder. This means that in our use case it takes up 10GB of disk quota for packages that could be shared. --remote-store already saves the compilation time for these shared packages, but does not remove the disk space requirement.
Doing this would simply require setting symbolic links to the shared $PACKAGE_ROOT directories. If combined with atomic builds and a flag (--prefer shared) to always take non-dev-mode packages from the shared location, if possible, it would provide a safe and stable development environment.
The text was updated successfully, but these errors were encountered: