possible bug / issue with formula cookbook documentation
brew config output
NA
brew doctor output
NA
Verification
- [X] I ran
brew updateand am still able to reproduce my issue. - [X] I have resolved all warnings from
brew doctorand that did not fix my problem.
What were you trying to do (and why)?
i was reading through the formula cookbook documentation and came across
https://github.com/Homebrew/brew/blob/master/docs/Formula-Cookbook.md
and specifically the below line,
https://github.com/Homebrew/brew/blob/68e895ad4d374b4a0022613a20bd046d6487dfd9/docs/Formula-Cookbook.md?plain=1#L713
where it states the prefix references the /usr/local/Cellar/foo/0.1
but in my test case i found when editing a formula see below using .prefix was referencing $(brew --prefix)/opt and not Cellar. not sure if this is suppose to the intended behavior or if .prefix is suppose to reference the Cellar and the documentation or source code needs to be updated to reflect the current path.
https://github.com/ipatch/homebrew-freecad/blob/1575ba8ad4e7d4a4ac95292ea5d90a5949edba32/Formula/freecad.rb#L82
What happened (include all command output)?
running the below command
brew install freecad -v -s
the path to the #{hbp}/opt dir instead of the Cellar dir is being used. not sure if using/calling .prefix is suppose to reference the Cellar or opt dir ?
What did you expect to happen?
i though calling .prefix would point the Cellar and not the opt dir according to the documentation.
Step-by-step reproduction instructions (by running brew commands)
brew tap freecad/freecad;
echo "semicolons cause i care about copypasta";
echo "i use fish";
cd (brew --repository freecad/freecad);
git remote add ipatch https://github.com/ipatch/homebrew-freecad;
git fetch ipatch;
git checkout freecad.update.to.0.20.release ;
brew install freecad/freecad/freecad;
then look at the output for the cmake_prefix_path
Basically the prefix to the formula being installed will point to the Cellar, but accessing the prefix of other formualae will point to the opt path. This is because Cellar paths are not stable and shouldn't really be referenced in other formulae as you risk, if that path ends up being baked somewhere in the resulting install, having to revision bump every time that other formula has a version/revision change, regardless if anything meaningful actually changed.
Pointing to the opt path should never be an issue in practice. Why do you need the Cellar path?
forgive if i'm missing something here, when i run brew install freecad (after running the previous steps, of course) i see the below output when install process errors / completes
==> ENV
HOMEBREW_CC: clang
HOMEBREW_CXX: clang++
MAKEFLAGS: -j8
CMAKE_PREFIX_PATH: /Users/chris/homebrew/opt/icu4c:/Users/chris/homebrew/opt/[email protected]:/Users/chris/homebrew/opt/readline:/Users/chris/homebrew/opt/sqlite:/Users/chris/homebrew/opt/[email protected]:/Users/chris/homebrew/opt/boost-python3.10:/Users/chris/homebrew/opt/llvm:/Users/chris/homebrew/opt/libffi:/Users/chris/homebrew/opt/jpeg-turbo:/Users/chris/homebrew/opt/qt@5::/Users/chris/homebrew/opt/cython:/Users/chris/homebrew/opt/tcl-tk:/Users/chris/homebrew/opt/openblas:/Users/chris/homebrew/opt/[email protected]:/Users/chris/homebrew/opt/sphinx-doc:/Users/chris/homebrew/opt/[email protected]:/Users/chris/homebrew
that's just a snippet but the cmake_prefix path is using the opt dir but when i editing the formula to use the .prefix in the initial setup command the .prefix points to the Cellar dir as seen below,
==> cmake -DCMAKE_INSTALL_PREFIX=/Users/chris/homebrew/Cellar/freecad/0.20 -DCMAKE_INSTALL_LIBDIR=lib -DCMAKE_BUILD_TYPE=Release -DCMAKE_FIND_FRAMEWORK=LAST -DCMAKE_VERBOSE_MAKEFILE=ON -Wno-dev -DBUILD_TESTING=OFF -DCMAKE_OSX_SYSROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -DHOMEBREW_PREFIX=/Users/chris/homebrew -DPYTHON_EXECUTABLE=/Users/chris/homebrew/bin/python3 -DPYTHON_INCLUDE_DIR=/Users/chris/homebrew/opt/[email protected]/Frameworks/Python.framework/Headers -DPYTHON_LIBRARY=/Users/chris/homebrew/opt/[email protected]/Frameworks/Python.framework/Versions/Current/lib/libpython3.10.dylib -DBUILD_SMESH=1 -DBUILD_QT5=1 -DFREECAD_USE_EXTERNAL_KDL=1 -DBUILD_FEM_NETGEN=0 -DBUILD_ENABLE_CXX_STD=C++17 -DCMAKE_PREFIX_PATH="/Users/chris/homebrew/opt/xerces-c;/Users/chris/homebrew/opt/opencascade;/Users/chris/homebrew/opt/hdf5;/Users/chris/homebrew/opt/coin3d;/Users/chris/homebrew/opt/qt@5;/Users/chris/homebrew/opt/vtk;/Users/chris/homebrew/opt/[email protected]/lib/cmake/PySide2-5.15.5;/Users/chris/homebrew/opt/med-file;/Users/chris/homebrew/Cellar/boost-python3.10/1.79.0;" -DFREECAD_CREATE_MAC_APP=1 ..
this something i noticed while troubleshooting a larger issue at hand. so i guess the documentation is correct in that using .prefix or calling .prefix on object (if that's how one says it 🤔) but it looks like the code (source the internal brew commands) could be mutating my input and using the opt dir instead of the Cellar
CMAKE_INSTALL_PREFIX is automatically set to the versioned Cellar directory because cmake needs to know where to physically put the files. The opt prefix is a symlink to the currently-installed version, that will point to .../Cellar/freecad/0.20 today, but .../Cellar/freecad/0.21 in the future.
Calling Formula["foo"].prefix from inside Formula["bar"] will return an opt path. Calling Formula["foo"].prefix from inside Formula["foo"].prefix will return a Cellar path.
This is by design. Cellar paths are implementation details that are internal to brew -- you don't want to show these unnecessarily to the build.
Calling
Formula["foo"].prefixfrom insideFormula["bar"]will return anoptpath. CallingFormula["foo"].prefixfrom insideFormula["foo"].prefixwill return aCellarpath.This is by design.
Cellarpaths are implementation details that are internal tobrew-- you don't want to show these unnecessarily to the build.
that definitely seems like a gotcha, and should be documented or at least brought to the attention of the reader in the formula cookbook. or maybe, i just over looked it, and thanks for the explanation.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.