Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MacOS native install: No formulae or casks found for tbb@2020 #1763

Closed
kevinpauli opened this issue Jun 6, 2024 · 6 comments
Closed

MacOS native install: No formulae or casks found for tbb@2020 #1763

kevinpauli opened this issue Jun 6, 2024 · 6 comments

Comments

@kevinpauli
Copy link

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
@JensTimmerman
Copy link

JensTimmerman commented Jan 4, 2025

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

@pierotofy
Copy link
Member

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.

@smathermather
Copy link
Contributor

smathermather commented Jan 5, 2025

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.

@JensTimmerman
Copy link

JensTimmerman commented Jan 5, 2025

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

@smathermather
Copy link
Contributor

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.

@JensTimmerman
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants