The INDI download page for OSX no more include the standalone INDI Server, it only indicate to compile the source or install Kstars.
This is a bit problematic for those that use application other than Kstars on the Mac.
Not a problem for me because I always compile INDI from source, but we cannot ask non-developer to do that.
There is a few way to solve the issue so I prefer to discuss them here before to do something on my own.
1) do nothing, tell the Mac users to use indigo.
2) package INDI with every application the same way this is done for Kstars. I not like this solution because the running version of INDI will depend on the application that start the server.
3) resurrect the standalone INDI Server. No idea how to do that? do we have the source code?
4) make a separate INDI installer package that install everything in /usr/local, the same as when you compile yourself. The problem in this case is if we must also package the dependencies or let Homebrew install them.
5) create a Homebrew formula for INDI so it can be installed in /usr/local with a simple "brew install indi", all the dependencies can be handled by Homebrew automatically. We can also package a script that do everything.
Personally I have a preference for 4) or 5) that are just two way to get the same result.
This also make it more easy if you want to run the WebManager on the Mac, or start the server with the system for example.
Any other idea? what are your preferences? is someone already working on this?
The INDI server stand-alone app was developed by cloud makers/ Peter Polakovic. But of course they developed INDIGO, so they moved on from that. I spent a lot of time porting kstars a couple of years ago and as a part of that, packaged up and internal indiserver. So I have spent a lot of time fixing INDI drivers to work on OS X. After my work last summer, INDI now supports on OS X almost everything that it does on Linux. I have maintained the ability for INDI to build in home brew using a script and now in craft for use in apps like kstars .
We already have a script that can build INDI on macs using homebrew that I wrote as well as another one using craft.
A home brew formula would not be too tough. It’s very similar.
The standalone app, while developed by cloud makers is open source and is published on INDI’s repo. I have no idea if it is up to date. We could ask Peter if we can do something with it?
We can talk/think about what might be best. Here are some options:
1: Home-brew build based bash script: Already have this, but mixed in with other things. Can very easily separate it.
2: Home brew recipe: This is simple to make since we already have the script and craft recipe
3: Homebrew cask: I think that Sean Houghton made one of these
4: Craft build recipe: Already have this too, but really meant for building apps like kstars, does not install to /usr/local. This could easily be used for building a new standalone indiserver app. This is what I was working on most recently.
5: Modifying Peter's indiserver app: Would require getting his permission, also seems to mostly be written in swift. I am most used to writing cross platform in Qt now. I probably would not do this.
6: Making a new INDIServer app in QT. This is something I have been considering. It could be just like Peter's app except it could work on all the platforms potentially. It might also be nice to have it be controllable just like the INDI Web Manger. This would be great to have on Macs, as well as Linux and maybe even windows (except INDI can't run on windows except in Cygwin or Windows Subsystem for Linux and WSL does not allow usb functionality)
7: Getting INDI Web Manger working on Macs. There are some really nice things about this one, since it is all python and shouldn't be too tough. But note, this would have to be tied in with a home-brew installation of INDI.
Number 6 im my list would require the most work, but could be the most interesting. The others could mostly be done fairly easily.
I thing an important point to not forget is whatever the solution we choice, it must be easy to upgrade to new version for both the user and the maintainer. If possible integrated in the INDI repo and using similar tools.
This introduction to say I have a software resembling your point 6) I do a few years ago that run on Linux and Mac: github.com/pchev/indistarter/wiki
But written using FreePascal and probably too much dependant on me, this can be use as an option but not as a global solution.
From what I understand, to upgrade a Homebrew recipe to a new version you just have to update the source download url, and eventually the build script to add new drivers.
With Bottles you can save the compilation time by installing directly the binaries instead, I think all the build dependencies I installed use Bottles and this is very quick.
About distributing binaries, what is your experience with INDI binary compatibility across MacOS version? do you use macosx-version-min ?
If automatic compilation is still required for the users it is important this is as simple as possible, for example do not require a full Xcode installation.
I not use Cask but if I understand correctly this just automate the install of an external package. You still need to build this package in some way first. This look more interesting to add something to /Applications.
I never use Craft, so I cannot give an advice here.
I not use them but I see there is build script for Dockers image with the INDI sources. Is Docker easily available on Mac? Is it a possible solution?
Yes, Web Manager is very interesting but this can be done in a second time, after the server command line is available. This can be for example another brew with the command line brew as a dependency.
Do you have a repo somewhere with your scripts to take a look?
With the old OS X build script that we developed back in 2016-2018, I built using a Mac OS X 10.11 El Capitan computer so that the binaries would be compatible with all subsequent systems. When QT ended support for anything less than 10.12, I had to speed up the work that I was already doing on craft so that we could get a completely craft-built kstars and INDI. The issue was that my build computer could not be updated to 10.12 and my new MacBook is running Mojave. Homebrew does NOT support building on a newer system and running the binaries on older systems. But craft can support that using the macosx-version-min build flag you mentioned. So far that mostly seems to be working fine. Though we might be having an issue with one of the binaries associated with either python or astrometry.net, but I'm looking into that. INDI has been working perfectly using craft.
My build scripts do not require a complete Xcode installation. They also can run automatically on your system.
The scripts that we build INDI in homebrew with are here: github.com/jamiesmith/kstars-on-osx
This could easily be modified so that it just builds INDI if desired.
But note that I haven't updated this script since I started relying solely on the craft version. I did make some changes since then. I made a better way to build the 3rd Party libraries before the 3rd Party drivers and we also have added a few more drivers. So this script does need some updating. I can easily do that if you think you would like to use homebrew to build INDI.
So yes for a start, you could take a look at one or both of my build scripts. Also I can create a new homebrew based build script for just INDI leaving out KStars if you like. That is just a matter of copying and pasting and updating a few outdated lines of code. Then we can think about where to go from there. Also, it does not have to be just one solution. There is no reason we can't maintain a homebrew recipe or build script at the same time as we have an app out there like the INDIServer app.
My guess would be that those who are coming from a linux environment would consider a homebrew recipe to be simplest. And those who are coming from a mac os x environment and have never seen homebrew before would find the method i have been distributing kstars ( in an app build with craft and then distributed in a dmg that they just have to drag and drop to their system to install) to be the simplest.
Did you get a chance to look at any of the recipes/scripts? I was waiting for you to get a chance to take a look at them before I did anything further. Note that there is a discussion to change the organization of the indi drivers into more than one repo. I'm pretty sure this will not impact the scripts too much, but it will change a few of the commands and maybe require a new recipe or two. (Really just copying and pasting another one and editing it slightly). So it might be good to wait a little bit before making the changes.
I might build a new version of KStars/INDI though before they make those changes to the repo just so users can have the latest version before a major change happens.
I am currently travelling for one week more and it not easy to connect remotely to my Mac virtual machine to test this procedure.
So at the moment I only look at the script source.
For me the Homebrew script is more easy to understand, this is almost what I do manually, except I stop after everything is in /usr/local. I like how you build the 3rdparty library first, this make the process very clean.
It is more difficult to follow how the Craft build work, I really need to try after I return home.
We originally used homebrew to do the whole thing, but the kde stuff on homebrew is a bit finicky. I found that one day it would build fine, but then another day they would have serious issues I would need to report. Also homebrew doesn’t actually support building for distribution so it ignores any request to set the min OS X version build variables. We can build INDI with homebrew but it will only work on computers equal to or newer than the build computer. We can’t reliably build kstars with homebrew.
The kde folks developed craft specifically for building and distributing kde programs and all their dependencies for Windows and mac. They do a pretty good job of keeping it up to date and fixing issues. It didn’t have all the recipes I needed but I was able to figure it out and write the ones i needed . I don’t think I included the craft recipes in my other post. Here you go:
I setup a new macOS 10.14 virtual machine to start clean.
Then to try the Craft build I follow manually the steps in your script github.com/rlancaste/kstars-on-osx-craft...ster/build-kstars.sh
I stop after "craft .... indiserver3rdParty"
Everything work fine and I have now a full INDI build in the craft directory.
Congratulation for your work on this Craft recipe. I like this way to build INDI and not install directly in /usr/local
Now I will skip the "Building Kstars" steps and continue at "Creating symlink", then generate-dmg with fix-libraries.
For my testing I will just try to copy everything in a dummy .app directory.
This sounds like a good plan to me. We will keep paying a lot of attention to craft because that is the way KDE packages up their apps and the INDI project is being managed by many of the same folks that are working on KStars. I don't think the recipes are 100% done yet, but they are definitely good enough to use to distribute stuff for now. This does allow us to largely ignore home-brew. I would like to get away from it entirely but there are still a few things that I haven't perfected the recipe for.
If you want to make some revisions, we could start working on a nice package with INDI specifically for OS X that doesn't include KStars.
There's just a couple of things.
1. I spent a lot of time making sure that everything could be packaged up in an app and then distributed and moved around to different places. So a number of the drivers need environment variables to be set in order to find the appropriate firmware files and similar things, unless they are in their homebrew locations. Right now in KStars, I set those environment variables at run time when KStars launches an INDI Server. This is really great because the user doesn't have to have homebrew installed, and they can put the app bundle anywhere they want on the computer. But any time the INDI server is run, they need to be set properly. Without KStars, what is the plan for setting this information?
2. In regards to #1, it might be good to develop a new program with a GUI to run an INDI server, or to use the old one that Peter made with updates to it. Thoughts?
3. Note that they are thinking of splitting the INDI repo into two parts. This won't cause any big issues as far as I can see, except that it will require that the recipes be updated . So if you do start with my recipes and/or scripts, please note that I plan to update them as soon as this change happens.
4. I am planning to submit my craft recipes to KDE as soon as they are ready. I did a lot of work on them last year and in January, but haven't worked on them since then. I have been really busy. I plan to look at them in detail again soon. Once I submit them, the script will become a lot simpler because it won't have to copy in the recipes I wrote, it can just use the craft recipes because mine would be included in there too. So when I do that, the script and recipes will change a bit.
That should be it. None of this would cause any major issues I don't think, but it is important to keep in mind moving forward since the scripts/recipes would need to be updated later if you write them now.
I think the biggest thing is the question of whether a GUI is needed? If so, it can be done with QT so it could be cross platform, rather than just for Macs. Or we could start with a similar program to what Peter had done. Or do you have another idea?