> Actually, these two approaches are slightly different I guess:
> - the installation script you are linking manages the
> installation and the subsequent steps, but doesn't manage the dependencies: for instance on my machine, it didn't find root and so manalyzer
> is built without root support.
> Maybe this is just something to adapt?

Yes indeed. From your perspective, you probably always want ROOT with MIDAS. But at PSI here we have several installation where we do not
need ROOT. These are mainly beamline control PCs which just connect to EPICS or pump station controls replacing Labview installations. All
graphics there is handled with the new mplot graphs which is better in some case.

I therefore added a check into install.sh which tells you explicitly if ROOT is found and included or not. Then it's up to the user to choose to
install ROOT or not.

> Brew on the other hand manages root and so knows how to link these two
> together.

If you really need it, yes.

> - The nice thing I like about brew is that one can "ship bottles" aka compiled version of the code; it is great and fast for
> deployment and avoid compilation issues.
> - I like that your setup does deploy and launch all the necessary executables ! I know brew can do
> this too via brew services (see an example here: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/r/rabbitmq.rb#L83 ), maybe worth
> investigating...?

Indeed this is an advantage of brew, and I wholeheartedly support it therefore. If you decide to support this for the midas
community, I would like you to document it at 

  https://daq00.triumf.ca/MidasWiki/index.php/Installation

Please talk to Ben <bsmith@triumf.ca> who manages the documentation and can give you write access there. The downside is that you will
then become the supporter for the brew and all user requests will be forwarded to you as long as you are willing to maintain the package ;-)

> - Brew relies on code tagging to better manage the bottles, so that it uses the tag to get a well-defined version of the
> code and give a name to the version.
> I had to implement my own tags e.g. midas-mod-2025-12-a to get a release.
> I am not sure how to do in the
> case of midas where the tags are not that frequent...

Yes we always struggle with the tagging (what is a "release", when should we release, ...). Maybe it's the simplest if we tag once per month
blindly with midas-2026-02a or so. In the past KO took care of the tagging, he should reply here with his thoughts.


> Thank you for the feedback, I will make the modifications (aka naming my formula
> ``midas-mod'') so that it doesn't collide with a future official midas one.

Nope. The idea is that YOU do the future official midas realize from now on ;-)


> Concerning the MidasConfig.cmake issue, this is what I need ...

Let's take this offline not to spam others.

Best,
Stefan