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
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?
Thank you for all this information, this help me a lot.
It take up to this week until I find some free time to continue to work on this. But now this is almost complete and I have some binaries build with Craft that can be tested.
The scripts build and install INDI in any .app, independently of the application itself.
For testing I update my IndiStarter application that can now use the embedded INDI server.
The point 1. in your last message was very useful, I find the environment variable to set in Kstars source. After I do that in my application there is no more problem with the skeleton files.
I can do only very limited test with the simulators because my only "Mac" is a virtual machine running on Linux KVM.
So I am very interested by any real test that can be done by installing the application from:
The application documentation is here:
Be sure to set a log file in the Setup options to get any error from the INDI server or driver.
This IndiStarter application can be a temporary solution for the point 2. , provide a GUI to start INDI on Mac. This give some time to discuss what solution we prefer on the long term. As I already say I not see IndiStarter as a permanent solution because I write it using FreePascal and this is not a language know by other INDI developers.
Tell me if you change the script for the repo split or inclusion in standard KDE craft so I can update my script.
I too have been very busy recently and have not had much time to devote to this, but now that we are getting close to summer, I should have some more time to do some development work. I will check out what you have done, probably within the next week or so.
I tested both your scripts in GitHub and the application on source force. Both work very well! I was able to build INDI and install it into a dummy app folder by running your scripts and following your directions. I was also able to use your INDIStarter app downloaded and installed from source forge to start up an INDI server and connect to it from KStars. This is a very good starting point. The only hiccup I found was that I had to create a root folder before running the script and I didn't know that till I ran it. That might be good to put in your directions. My script automatically makes the folder if it doesn't exist. Your plan might be better in case the user has the wrong folder in the build-env file. But other than that, there were no problems running it. Note, that I did not test INDIStarter with any real equipment yet, just the simulators.
One think that I really like about what you did is that you separated the INDI build from the installation into the app. That is great for folks like you who might want the stable version and don't want to build INDI every time from source. Once INDI is built, it only takes a moment to install INDI into your app. The way I currently have it set up, it builds the latest version of INDI every time, which is fine for what I am doing since we are working on both INDI and KStars at the same time, so I'm trying to get all the latest stuff that I add/change in INDI into the latest version of KStars each time. But of course it takes longer and the latest version of INDI could potentially have bugs in it. On that same note, I did note that in your code, you are using the latest version of INDI, for your application, maybe it should be the newest stable one?
So now it is very likely that you could use these scripts as a platform to embed INDI into some of your other projects like ccd ciel, phd2, or skychart just like we did for KStars. Then users could start and control the INDIServer inside them. That would be nice. Do you plan to do that?
Your indistarter program is very nice and works very similarly to the now defunct INDIServer app by cloud makers. I think that users will like that a lot. I do like the simplicity that the clouldmakers INDIServer app has, and yours is just as nice. As you mention, this is a temporary move of course, because it would probably be best to code this in a more familiar language/platform. Maybe a cross platform QT app would be nice, or maybe something like the INDI Web Manager for Macs. For now, though, this seems to work well.
One other note is related to the CCD simulator. In order to include stars in the simulator images, it needs GSC. In KStars, I added an option that allows the installation of GSC if the user desires. I don't think it should be included in any app by default because it is so large (300 MB). When the INDI server is run, an environment variable can be set to point to the GSC folder. That is what I do in KStars. The CCD Simulator's stars in INDI are VERY nice because you can do all kinds of tests for your programs with it since they can test focus algorithms, plate solving algorithms, guiding algorithms, and imaging algorithms. They also are very nice for beginners to the software because the beginner can do a full observing run and test EVERYTHING about the program by just sitting on the couch and using the fake stars from the simulators.
This is a VERY good start. I should have a decent amount of time this summer to help you with some of this. I do have some plans for some things I would like to do to my scripts, the craft recipes, INDI, and KStars. I should also be able to work on this as well. I think this is a great project because it will really help to improve and expand INDI and its use.
I have updated the readme to specify you must create the src directory in home, mkdir ~/src , cd ~/src, before to git clone. With this steps it must work without editing the environment file.
My intent is to use the stable version but I try this change because "default" still point to 1.7.6. Is it possible to change the craft file to use 1.7.8 ?
I see now I make an error about the INDI version selection, I want to try "Latest" but I write "latest" in the script, so in fact it still use 1.7.6.
At the moment I include the installation of INDI in my application in a very simple way. After I run the scripts that install in the empty test.app I make a tar file of the Contents directory, then I extract this tar in my real application part of it's "make install". This is possible for me because I am sure there is no file overlap. This way I only have to make a new build of INDI when the version change.
I not plan to include INDI in ccdciel, phd2 or skychart because the INDI server is a unique resource on the computer and I not like the idea you can get a different version of the server if you first start one application or the other. So it is probably better to use an independent way to start the server, like IndiStarter or it's future replacement.
You not have this problem with Kstars because it is a complete application, most users run only Kstars and it make sens to include the server.
I use a lot the simulator with the GSC for the application development. I not include the binary in my script because "craft gsc" is commented in your script build-kstars.sh so I not try it. Do it build the binary or also install the catalog?
A good solution will be to include the gsc binary in MacOS/indi/ but let the users that want to use it to install the catalog data out of the application directory.
I do some more testing by trying to start every driver, specifically those in 3rdparty, to look for dependency issue and I found some you can probably help me to solve.
qhy_ccd is not build at all and I not see any message about it in the build log from "craft indiserver3rdPartyLibraries" or "craft indiserver3rdParty". Is some other files, like SDK from QHY, that need to be installed first?
the SBIG driver do not load because of missing libsbig.dylib.
It is build in ~/src/indi-mac/craft/lib/ but from the script install/fix the library there is the messages:
HAVE TO COPY [libsbig.dylib] from [/usr/local/lib/libsbig.dylib] to Frameworks
cp: /usr/local/lib/libsbig.dylib: No such file or directory
Is this error because this location is set in the library?
otool -L craft/lib/libsbig.dylib
/usr/local/lib/libsbig.dylib (compatibility version 1.0.0, current version 1.0.0)
indi_eqmod_telescope fail to load the svd math plugin. It look like EnumeratePlugins search at the right location and found it but dlopen try to load it from the build location.
the message is :
Driver indi_eqmod_telescope: EnumeratePlugins - cannot load plugin /Users/pch/src/indi-mac/craft/lib/indi/MathPlugins/libindi_SVD_MathPlugin.dylib error dlopen(/Users/pch/src/indi-mac/craft/lib/indi/MathPlugins/libindi_SVD_MathPlugin.dylib, 2): image not found
The library itself look right:
otool -L testapp/test.app/Contents/Resources/MathPlugins/libindi_SVD_MathPlugin.dylib
@rpath/libindi_SVD_MathPlugin.dylib (compatibility version 0.0.0, current version 0.0.0)
Yes i can update the recipe to include 1.7.8, thats not a problem.
I commented out gsc because we decided to not include gsc in the dmg with kstars due to its size, but instead to make it a separate download from a server by selecting the option inside kstars. I left in the recipe and the commented out in the script, however, because that leaves a way for people like developers to build gsc so they can install it, build it, include it, or whatever. The gsc build, builds everything gsc needs including the files and the executable and puts them in a subfolder of the craft root folder. Then you can put it wherever you like. Then when you run the indiserver, just pass the location in an environment variable called gscdat.
I will look at those 3 drivers today. All sdks and dependencies should be handled by the script. There are no installation or build envrionment requirements before running it. I know qhy has needed to be turned off a few times due to bugs in their code. It looks like the path for sbig might be off. But i will check all of them.
I just updated the stable build to 1.7.8. One note about that though. The other things you were asking about, QHY, LIBSBIG, and EQMOD, any issues with their installation could possibly be changes in INDI, instead of in my script or recipe. So that does mean that if you use the stable build, any changes that I make to INDI now won't be in 1.7.8.
I just checked QHY. It is currently turned on. I built the latest version of KStars last night and it built QHY too.
Here is what I have in my 3rd Party Libraries build folder and in my INDI build folder (except I cut off a little from the top and bottom on the INDI build since there is so much). Is this the same as yours?
For SBIG, you are right, the SBIG dylib is in the craft lib folder, but for some reason at the end it isn't copying it to the right place. I'm pretty sure it is an rpath issue and that should be easy to solve. I will do that now.
Ok I fixed SBIG in the recipe. It was an issue with the rpath of the library. I just set it in the recipe. That is the solution I used several times in the recipes for binary files that just get copied. The sbig library is one of those files because that is how SBIG wants us to handle their library files, as a binary blob.
Ok I just sent a pull request to Jasem to fix my mistake in the path to the math plugins. I also revised the recipe for gsl because when I was looking into this problem, I found that there was an issue with gsl that was related to this. Once Jasem accepts the pull request, it should work just fine.