MacOS native install: No formulae or casks found for tbb@2020
How did you install ODM? (Docker, installer, natively, ...)?
natively on mac
What is the problem?
This line in configure_macos.sh:
brew install cmake gcc@12 [email protected] tbb@2020 eigen gdal boost cgal libomp
Is giving this error:
Warning: No available formula with the name "tbb@2020".
==> Searching for similarly named formulae and casks...
Error: No formulae or casks found for tbb@2020.
What should be the expected behavior? If this is a feature request, please describe in detail the changes you think should be made to the code, citing files and lines where changes should be made, if possible.
It should configure macos correctly
How can we reproduce this? What steps did you do to trigger the problem? If this is an issue with processing a dataset, YOU MUST include a copy of your dataset AND task output log, uploaded on Google Drive or Dropbox (otherwise we cannot reproduce this).
git clone https://github.com/OpenDroneMap/ODM
cd ODM
bash configure_macos.sh install
I'm seeing the same issue, tbb is an intel library, threading building blocks, the are not planning on supporting it on arm, however it seems tbb@2022 is available in brew.
a workaround is to not use the configure script but build completely manually, I started looking into this, but the build process is a mess, make e.g. starts to download zips and clone repos and checks out branches, instead of properly defining the dependencies in the readmes and allowing us to install those. I guess this fits into the business model of charging for an installer/compiled binary and not giving support to manually install.
They use a lot of out of date software, e.g. old unsupported python 3.8 the requirements.txt also don't seem up to date, matplotlib3.3 doesn't work with recent python, remove the version numbersin requirements.txt for all packages to install the latest version, and not old outdated versions.
then they download manually GDAL-3.6.2.tar.gz etc
Let's install these packages with brew, and remove the
SETUP_EXTERNAL_PROJECT lines from CMakeListst.txt in superbuild dir
and remove everything after line 169:
set(custom_libs #OpenSfM
brew install cmake gcc python tbb eigen gdal boost cgal libomp
pip3 install -r requirements.txt -U --break-system-packages --user
pip3 install gdal --user --break-system-packages
cd SuperBuild
brew install ceres-solver pdal hexer opencv gflags
# this is for fish, use corresponding export for bash
set -gx LDFLAGS "-L/opt/homebrew/opt/libomp/lib"
set -gx CPPFLAGS "-I/opt/homebrew/opt/libomp/include"
git clone --recursive https://github.com/mapillary/OpenSfM
cd OpenSfM
git submodule update --init --recursive
pip3 install -r requirements.txt -U --break-system-packages --user
But now I’m stuck there, since this project also still uses outdated python
I'll have to update on a later point when I have some more time to walk trough that project
I guess this fits into the business model of charging for an installer/compiled binary and not giving support to manually install.
This has nothing to do with the business model, and lots to do with the complexity that is building ODM from source. We recommend people use docker to run ODM on macOS, which doesn't cost anything and works out of the box.
We recommend people use docker to run ODM on macOS, which doesn't cost anything and works out of the box.
As Piero indicates, @kevinpauli @JensTimmerman, please use the README or docs for directions on how to install and use.
I will close this issue for now. If anyone has a pull request to address native mac install, we can re-open as appropriate.
Docker works if you are willing to/able to install docker on your machine. (Requires admin rights e.g) to run the application
And the software stack used on the docker images is completely out of date and no longer supported.
directing to the documentation is a bit weird. the issue arrived from following the steps in the readme https://github.com/OpenDroneMap/ODM?tab=readme-ov-file#native-install-macos
the configure mac script fails because tbb@2020 is no longer present in brew
Docker works if you are willing to/able to install docker on your machine. (Requires admin rights e.g) to run the application
Yes, there are limitations to docker, e.g. admin rights. It is possible to run within other containerization that don't require the same escalation, e.g. apptainer. Docker is the recommended approach at this time, but feel free to test and write documentation for use in other container systems as appropriate.
But what if you want to create your own modifications and run those?
This is beyond the scope of this issue to document, but I tend to use a workflow similar to this: https://docs.opendronemap.org/tutorials/#development-and-testing-of-odm
directing to the documentation is a bit weird. the issue arrived from following the steps in the readme https://github.com/OpenDroneMap/ODM?tab=readme-ov-file#native-install-macos
Cool. That wasn't made clear in the initial issue, so I missed that was what was being referenced. Thanks for linking directly to it to clarify the need.
A pull request updating with a good or updated workflow would be most appreciated. Alternatively a pull request with an update to the readme to deprecate or warn in the native section would be a second best solution.
And the software stack used on the docker images is completely out of date and no longer supported.
If you are willing to take on stack updates in a serious way, let us know.
A pull request updating with a good or updated workflow would be most appreciated. Alternatively a pull request with an update to the readme to deprecate or warn in the native section would be a second best solution.
And the software stack used on the docker images is completely out of date and no longer supported.
If you are willing to take on stack updates in a serious way, let us know.
Yes, that's wat I started on working on, and what I documented here, I have a good bit of experience in this area, but unfortunately I lack the personal free time to do this at the moment. If someone were to offer a sponsorship I would love to start working on that.
This issue is still present, after following basic steps in the documentation.
I would suggest to either officially drop native Mac builds (e.g. remove from README) or re-open and to leave this open in the form of a tracking ticket.