mirror of
https://github.com/spacedriveapp/spacedrive
synced 2024-07-02 10:03:28 +00:00
cf482f5621
* Attempt at building our own ffmpeg dylibs for macOS
- Create dockerfile to setup osxcross and required host dependencies for cross-compiling ffmpeg for macOS
- Create script to setup required macOS dependencies and build ffmpeg for both x86_64 and aarch64
* Improve dockerfile to better use docker's cache
- Attempt at fixing arm64 build (still not there yet)
* ARM64 sucessfully compiles \o/
- Use clang for everything (e.g. linker, assembler, ...)
- Remove -lc++ because it is now handled internally thanks to a patch
- Apply 3 open PRs to osxcross as external patches to solve some of our problems
- PR 180 reduces the macports dependencies size by prefering non universal libs for x88
- PR 314 adds the -lc++ flag for macOS SDKs >= 11.1
- PR 379 fix macports pulling incorrects deps for SDK11 and adds support for SDK13 (future proofing, as it does nothing for us rigth now)
* Fix relink and copy logic in ffmpeg build script
- Ensure ffmpeg and dependencies dylibs are correctly relinked and copied over to the output directory
- Copy includes from ffmpeg and dependencies to allow for dev building against these dylibs
- Set up symlinks for all dylibs to the common `lib` directory
- Remove superfluous linker and compiler options
- Add `-headerpad_max_install_names` linker option to accommodate the required relink changes
- Remove `--disable-fft` for the arm64 build, as it doesn't seem to be required nowadays
- Allow `swresample` and `avdevices` to be compiled as they seem to be expected to exist by `ffmpeg-sys-next`
- Disable ffmpeg program compilation
- Fix dylibs id to match their new expected location
- Fix ffmpeg dylibs inter-linkage not being updated
- Add custom patch for osxcross macports to load already downloaded files from cache
- Remove the requirement for specifying the darwin version in the Dockerfile
- Enable docker cache for macports
- Move arm min macOS version ARG to the top
* Attempt at building ffmpeg with github actions
- Split osxcross setup into it's own Dockerfile to allow exporting it as a image to Dockerhub
- Create a github action to build ffmpeg
- Add osxcross patch for PR 372 for future proofing (Add support for macOS SDK 13.1)
* Remove incompatible step name
* Change FFMPEG_VERSION to string to avoid yaml weird type casting
* Start to use our ffmpeg build in the macOS
- Adjust the macOS setup script to download our ffmpeg build, also replace installing protobuf compiler from brew with grabbing it from it's own repository
- Some misc improvement to the *nix setup script
- Fix ffmpeg build script not copying static libs (for when we may want to statically link ffmpeg)
- Fix ffmpeg build script not taking into acount possible libraries that are multiple paths deep in /lib
- Update CI to actions/checkout@v3, v2 is deprecated
- Update ffmpeg build CI to not xz the artifacts, as github already zips it anyway
* Fix macOS setup not finding the ffmpeg artifact due to a jq script mistake
- Comment out embeeding static libs in ffmpeg artifact for now, as they take too much space
- Remove incorrect dockerfile settings from editorconfig
* Fix protobuf download in macOS
- Fix Framework directory creation not following script's dir but cwd
- Improve download logic to avoid being rate limited on failures
- Return to using xz for ffmpeg build, as it saves quite a bit of space
* Replace `OSTYPE` with `$(uname)` for a more standardized way to check which os is running
- Fix mobile check using `==` instead of `=` in test command
* Fix syntax error in bash 3.x (which is the default in macOS)
- Fix jq not downloading all deps and being placed in the incorrect directory
* Fix incorrect install_name_tool arguments
- Remove leading './' when referencing ffmpeg libs during build
* Fix protoc not being executable
- Fix some error messages
* jq throw input when it is invalid
- Enable debug log in setup script when running in CI
* Add a dev.js build script for desktop app
- Remove dll copy from setup-system.ps1, now done by dev.js
- Minor rework to build.js to improve signals and stdio handling
* Configure cargo to use FFMPEG_DIR and PROTOC envvars on macOS
* Pass GITHUB_TOKEN to macOS setup script in CI
* Replace simple curl with gh_curl in github request
* Fix some ctrl+c/ctrl+v typos
* Add missing ffmpeg deps
- Fix missing symlinks for ffmpeg libs in the output_dir/libs
- Change arm64 minimum macOS target to 11.2 due to libbrotli only being available precompiled to this version
- Add more options to ffmpeg configure in an attempt to reduce its size + improve performance
* Rework ffmpeg build script to create a FFMpeg.framework instead of loose dylibs
- Disable unused postproc and enabled missing required protocols in ffmpeg configuration
- Adjust Dockerfile and setup-script to handle the new FFMpeg.framework
* Fix setup script incorrect linking logic for FFMpeg.framework
* Forgot to remote the leading path in the lib/header linking logic for FFMpeg.framework
* Enable size optimization for ffmpeg
- Remove Frameworks directory before setting it up in setup-system.sh
* Revert lib id to use `@executable_path/../Frameworks/` instead of `@rpath`
- `@rpath` breaks dev builds
- Add logic to create less versioned versions of dylibs in setup-system script, due to it being required for compiling ffmpeg-sys-next (not required during runtime, just for compilation)
- Add scripts/deps to gitignore
* Fix ffmpeg build script not copying unversioned symlinks to FFMpeg.framework
- Remove unecessary unversioned symlink logic from setup-system
- Add new build scripts for dev and prod that setup the environment and tauri to correctly point to FFMpeg.framework
- Rework windows setup-system script to follow the same logic as in macOS setup-system
* Attempt at fixing windows setup script
- Add powershell editorconfig
* Attempt to fix Windows CI
* Fix some mistakes in the build scripts
- Replace toml lib with something more used and maybe better?
- Attempt to fix Windows CI
* Fix some more problems with the build script
* Another attempt at fixing windows CI
* Some more fixes for the windows setup script
* Add build.js step to release CI
- Implement patch only mode for build.js when running under CI
- Implement appeding extra env in cargo config in env.js
- Only run windows dlls copy in dev in env.js
- Another attempt at fixing windows CI
* Maybe this will make the windows CI happy?
* Windows CI why dont you work, whyyy?
* Try to apease the Windows CI Gods
- Disable updater build in macOS, due to tauri-apps/tauri#3933
* Fix build.js extra env vars
- Uncomment parts of setup-system.ps1 to check if it keeps working
* Uncomment another section and see if windows CI will complain
* uncomment some more of setup-system.ps1
* Use Start-Process for robocopy instead of executing it directly
- Only raise an error if robocopy exists with a status code >=8
- Revert build.js macOS specific bundles change
- Disable updater for now
* Remove updater from cargo.toml
* Add -PassThru to Start-Process to ensure we get and Process obj back
* Comment out more of updater
* Improve documentation for both of the docker containers
- Fix a harcoded install_name_tool call in the ffmpeg-build-macos.sh script
* Configure tauri to copy ffmpeg dlls to windows prod version
- Fix windows dlls copy on dev
- Stop replacing tauri.conf.json, except on CI, for prod builds and use a tauri.conf.patch.json for any required changes
- Don't unset macOSPrivateApi on prod build, we need it for the transparent background
- Fix dev.js not exiting when the spawned command was over
* Fix windows not find protoc
- Fix missing import in env.js
* Fix Windows Dlls copy logic for prod build
- Fix dev script failing due to missing env
- Implement error handler to spawned process
* Format + Fix pnpm-lock
* Fix video thumb generation failing on Windows due to bad path to CString conversion logic
* Fix mobile build
- Greatly improve windows setup-script error handling
- Install LLVM with winget instead of downloading exe from github
* Improve CI a bit
- Fix mobile CI not using github token to avoid being rate limited
* Fix pnpm not accesible to actions/setup-node
* Skip pnpm check on CI
* Fix pnpm skip not working
- Fix pnpm cache check missing a step
* Only lock action to major versions
* CI really doesn't like running robocopy directly
* Attempt to build our own patched tauri bundler
* Trigger new workflow
* Fix attempt for patched tauri action tests
- Disable cache for patched tauri action
- Enable package publishing for patched tauri action
* Attempt fix patched tauri publish
* Remove commented code from patched tauri workflow
- Replace deprecated `actions-rs/toolchain` with `dtolnay/rust-toolchain`
* Fix url patching logic for publishing step of patched tauri package
* Fix prepublishOnly command for patched tauri package
* Adjust patched tauri package package.json
* Also patch the specific os/arch sub packages
* Instruct napi to stop doing github releases
* Patch package.json befor build
* Re-enable updater
- Patch tauri cli to workaround a tauri bug that prevented use from bundling frameworks in the updater
- Update tauri/api to 1.3 and tauri/cli 1.3.1
- Add target triple in the release artifacts name
- Use ubuntu-20.04 instead of ubuntu-latest
- Configure release workflow to build to all supported platforms
- Replace `tauri-apps/tauri-action` with simply calling `pnpm desktop build`
- Simplify tauri-patched-cli-js to only build the required macOS binaries
- Unify build.js and dev.js in a tauri.js build script, which now acts as an all around wrapper for the tauri/cli
* Restore incorrectly removed step from `tauri-patched-cli-js`
* Disable auto-run of tauri-patched-cli-js
- Update setup-system.sh with the latest tauri-patched-cli-js artifacts
* Forgot to mkdir bin
* Fix pnpm-lock.yaml not being up to date
- Remove pnpm deps caching
* Fix variable name conflict
* Enable the updater build conditionally
- Enable release workflow to test it
* Fix artifacts not being published
- Change macOS on arm64 minimumSystemVersion to 11.2
- Commented out rust cache to check if this is the culprit to the low memory problem on windows runner
- Add some debug log to tauri.js
* Fix release workflow artifact uploading
* Specify which bundles to build on each platform
- Attempt fix apple arm build
- Don't include internal deb archives in linux updater artifact
* Attempt to fix apple arm build
- Fix dmg background not applying
* Fix incorrect semver usage
* Patch swift-rs to see if that fix apple arm64 release build
* Update swift-rs submodule
- Remove unused deps lodash.merge
* Configure so only release workflow runs without cache
- Improve tauri.js logs
* Ignore `crates/swift-rs`
* Revert "Ignore `crates/swift-rs`"
- Remove `crates/swift-rs` before running `cargo fmt`
This reverts commit
|
||
|---|---|---|
| .cargo | ||
| .cspell | ||
| .github | ||
| .vscode | ||
| apps | ||
| core | ||
| crates | ||
| docs | ||
| extensions | ||
| interface | ||
| packages | ||
| .editorconfig | ||
| .eslintignore | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| .npmrc | ||
| .nvmrc | ||
| .prettierignore | ||
| .prettierrc.js | ||
| .rustfmt.toml | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| cspell.config.yaml | ||
| LICENSE | ||
| package.json | ||
| pnpm-lock.yaml | ||
| pnpm-workspace.yaml | ||
| README.md | ||
| tsconfig.json | ||
| turbo.json | ||
Spacedrive
A file explorer from the future.
spacedrive.com »
Download for
macOS
·
Windows
·
Linux
·
iOS
·
watchOS
·
Android
~ Links will be added once a release is available. ~
NOTE: Spacedrive is under active development, most of the listed features are still experimental and subject to change.
Organize files across many devices in one place. From cloud services to offline hard drives, Spacedrive combines the storage capacity and processing power of your devices into one personal distributed cloud, that is both secure and intuitive to use.
For independent creatives, hoarders and those that want to own their digital footprint, Spacedrive provides a free file management experience like no other.
What is a VDFS?
A VDFS (virtual distributed filesystem) is a filesystem designed to work across a variety of storage layers. With a uniform API to manipulate and access content across many devices, VDFS is not restricted to a single machine. It achieves this by maintaining a virtual index of all storage locations, synchronizing the database between clients in realtime. This implementation also uses CAS (Content-addressable storage) to uniquely identify files, while keeping record of logical file paths relative to the storage locations.
The first implementation of a VDFS can be found in this UC Berkeley paper by Haoyuan Li. This paper describes its use for cloud computing, however the underlying concepts can be translated to open consumer software.
Motivation
Many of us have multiple cloud accounts, drives that aren’t backed up and data at risk of loss. We depend on cloud services like Google Photos and iCloud, but are locked in with limited capacity and almost zero interoperability between services and operating systems. Photo albums shouldn’t be stuck in a device ecosystem, or harvested for advertising data. They should be OS agnostic, permanent and personally owned. Data we create is our legacy, that will long outlive us—open source technology is the only way to ensure we retain absolute control over the data that defines our lives, at unlimited scale.
Roadmap
View a list of our planned features here: spacedrive.com/roadmap
Developer Guide
Please refer to the contributing guide for how to install Spacedrive from sources.
Architecture
This project is using what I'm calling the "PRRTT" stack (Prisma, Rust, React, TypeScript, Tauri).
- Prisma on the front-end? 🤯 Made possible thanks to prisma-client-rust, developed by Brendonovich. Gives us access to the powerful migration CLI in development, along with the Prisma syntax for our schema. The application bundles with the Prisma query engine and codegen for a beautiful Rust API. Our lightweight migration runner is custom built for a desktop app context.
- Tauri allows us to create a pure Rust native OS webview, without the overhead of your average Electron app. This brings the bundle size and average memory usage down dramatically. It also contributes to a more native feel, especially on macOS due to Safari's close integration with the OS.
- We also use rspc which allows us to define functions in Rust and call them on the Typescript frontend in a completely typesafe manner, so no unnecessary bugs make it into production!
- The core (
sdcore) is written in pure Rust.
Monorepo structure:
Apps:
desktop: A Tauri app.mobile: A React Native app.web: A React webapp.landing: A React app using Vite SSR & Vite pages.
Core:
core: The Rust core, referred to internally assdcore. Contains filesystem, database and networking logic. Can be deployed in a variety of host applications.
Packages:
client: A TypeScript client library to handle dataflow via RPC between UI and the Rust core.ui: A React Shared component library.interface: The complete user interface in React (used by appsdesktop,webandlanding)config:eslintconfigurations (includeseslint-config-next,eslint-config-prettierand alltsconfig.jsonconfigs used throughout the monorepo.macos: A Swift Native binary for MacOS system extensions.ios: A Swift Native binary (planned).windows: A C# Native binary (planned).android: A Kotlin Native binary (planned).