Thank you received: 8
Our main plan is to use this script written by Jamie to set everything up whether you are doing development or making a deployable disk image:
github.com/jamiesmith/kstars-on-osx.
There are two options, the cmake version and the "emerge" version. The emerge version is meant for deployment and the cmake version is meant for coding.
Ages ago, we used cmake along with a list of instructions (which I based on your original instructions) that we were refining to make it all work. We refined it all through several iterations and I did a ton of kstars coding until we got everything working, icons, windows, Indiserver, astrometry, and xplanet. Then I found out about emerge, which simplified everything, sped things up a bit, and even fixed some problems. Around that time, I also had the idea that we could bundle it up (including indi, astrometry, xplanet, etc) and make everything very simple for the end user. Most end users would never want to deal with home-brew let alone editing code. While I was doing the c++ coding, Stephane learned how to bundle everything up in the dmg and make it deployable. And Jamie wrote a script for us so that all we have to do to deploy the app to a dmg is run his script.
In fact, now all the end user has to do is download our dmg, and the data directory gets copied to the right place the first time they open kstars and astrometry.net is ready to function (except that the end user needs to download and install some index files). And if they want gsc to work with simulators, they need to download and install it to their data directory. We are still thinking about how to make these last steps easier.
The problem with the emerge version is that it doesn't make a way that you can edit and test kstars code like I needed to do, so I was still relying on our outdated series of steps to install via cmake, even though we had fixed several problems in the emerge based version that made it work perfectly. When I got my new MacBook Pro, I was having trouble getting my original steps to work. So I asked Jamie to write into his script the ability to use cmake for the last part instead of emerge. He did it, but there were still problems and Stephane and I worked over the last couple of days to get it working fully. I got stuck yesterday, but Stephane cracked it using some great sleuthing. Now I have a fully working editable kstars on my computer from Jamie's script. I posted the steps today. Unfortunately, the steps must be run prior to his script because it doesn't yet include Stephane's solution. I will get a link for you to the steps that worked for me.
The emerge version worked yesterday and produced a perfectly workable dmg! But somebody in the emerge team decide to change the name of emerge to craft today, breaking Jamie's script. The problem will be solved in the near future, but for now it won't work.
To follow up my last post, here is a (mostly) working dmg, ready to go. It can be used on a Mac with El Capitan or Sierra and it has an internal Indi server. One problem is that I think it does not have the astrometry folder in there, because at the time I think they were testing some things and disabled the copy of the astrometry folder into the app bundle.
www.indilib.org/forum/ekos/525-ekos-on-m...tml?start=1032#12486
And here is my list of steps for getting things set up for Jamie's script (at least until Jamie incorporates some of it). Note that this is a way to shortcut the brew qt5 with dbus installation which takes forever and instead uses the version of qt that downloads with Qt Creator. At the end, I still had to copy in the astrometry folder, the data folder, and the xplanet folder because Jamie hasn't added that to the cmake version of his script yet (but it is in the emerge version if you want to see what is needed ~ line 507 in build-kstars.sh). Or you can just do what I do, keep a copy of the stuff that needs to go into the app bundle on your desktop and whenever they disable the copying due to testing something it is right there ready to copy into the app bundle.
www.indilib.org/forum/ekos/525-ekos-on-m...tml?start=1020#12470
If it helps here is the structure of our app bundle:
The Data directory files go into /Contents/Resources/data/ and will be copied into their proper place in application support on application start if they are not there yet.
The Indi drivers and xml files all go into /Contents/MacOS/indi/ and you can just copy and paste them there from /usr/local/bin and /usr/local/share/indi .
The astrometry files all go into /Contents/MacOS/astrometry/ and what you need to copy is the bin and lib folders from the brew astrometry.net to make it work
The astrometry.cfg file goes into /Contents/MacOS/astrometry/bin/. Don't worry about the add_path variable, it will be set properly on application start and/or when you try to use the offline plate solver.
Any astrometry.net index files need to be placed into ~/Library/Application Support/Astrometry/. You can even use the Cloudmakers software to download them and install them since it uses the same location.
The xplanet files go into /Contents/MacOS/xplanet and all you need is the bin and share folders to make it work.
Your planet textures go into /Contents/MacOS/xplanet/share/xplanet/images/
GSC gets placed into the data directory in ~/Library/Application Support/kstars/
Stephane and Jamie, please correct me if I am wrong on any of this. I think I got it right. Thanks!
Ekos on Mac OS X ?
Posts:
25
I'm finally back in action on macos and I've got the official mainline kstars building - but the resources aren't copied into the data folder as part of the build so they don't get copied to the Application Support folder on application start. Is this expected to run without a packaging or install build?
Also, are you guys keeping a forked git repo or branch with all of the OSX work you've done? It's getting difficult to keep track of the progress in this gigantic thread
Also, are you guys keeping a forked git repo or branch with all of the OSX work you've done? It's getting difficult to keep track of the progress in this gigantic thread
seanhoughton wrote: I'm finally back in action on macos and I've got the official mainline kstars building - but the resources aren't copied into the data folder as part of the build so they don't get copied to the Application Support folder on application start. Is this expected to run without a packaging or install build?
Also, are you guys keeping a forked git repo or branch with all of the OSX work you've done? It's getting difficult to keep track of the progress in this gigantic thread
Our main plan is to use this script written by Jamie to set everything up whether you are doing development or making a deployable disk image:
github.com/jamiesmith/kstars-on-osx.
There are two options, the cmake version and the "emerge" version. The emerge version is meant for deployment and the cmake version is meant for coding.
Ages ago, we used cmake along with a list of instructions (which I based on your original instructions) that we were refining to make it all work. We refined it all through several iterations and I did a ton of kstars coding until we got everything working, icons, windows, Indiserver, astrometry, and xplanet. Then I found out about emerge, which simplified everything, sped things up a bit, and even fixed some problems. Around that time, I also had the idea that we could bundle it up (including indi, astrometry, xplanet, etc) and make everything very simple for the end user. Most end users would never want to deal with home-brew let alone editing code. While I was doing the c++ coding, Stephane learned how to bundle everything up in the dmg and make it deployable. And Jamie wrote a script for us so that all we have to do to deploy the app to a dmg is run his script.
In fact, now all the end user has to do is download our dmg, and the data directory gets copied to the right place the first time they open kstars and astrometry.net is ready to function (except that the end user needs to download and install some index files). And if they want gsc to work with simulators, they need to download and install it to their data directory. We are still thinking about how to make these last steps easier.
The problem with the emerge version is that it doesn't make a way that you can edit and test kstars code like I needed to do, so I was still relying on our outdated series of steps to install via cmake, even though we had fixed several problems in the emerge based version that made it work perfectly. When I got my new MacBook Pro, I was having trouble getting my original steps to work. So I asked Jamie to write into his script the ability to use cmake for the last part instead of emerge. He did it, but there were still problems and Stephane and I worked over the last couple of days to get it working fully. I got stuck yesterday, but Stephane cracked it using some great sleuthing. Now I have a fully working editable kstars on my computer from Jamie's script. I posted the steps today. Unfortunately, the steps must be run prior to his script because it doesn't yet include Stephane's solution. I will get a link for you to the steps that worked for me.
The emerge version worked yesterday and produced a perfectly workable dmg! But somebody in the emerge team decide to change the name of emerge to craft today, breaking Jamie's script. The problem will be solved in the near future, but for now it won't work.
seanhoughton wrote: I'm finally back in action on macos and I've got the official mainline kstars building - but the resources aren't copied into the data folder as part of the build so they don't get copied to the Application Support folder on application start. Is this expected to run without a packaging or install build?
Also, are you guys keeping a forked git repo or branch with all of the OSX work you've done? It's getting difficult to keep track of the progress in this gigantic thread
To follow up my last post, here is a (mostly) working dmg, ready to go. It can be used on a Mac with El Capitan or Sierra and it has an internal Indi server. One problem is that I think it does not have the astrometry folder in there, because at the time I think they were testing some things and disabled the copy of the astrometry folder into the app bundle.
www.indilib.org/forum/ekos/525-ekos-on-m...tml?start=1032#12486
And here is my list of steps for getting things set up for Jamie's script (at least until Jamie incorporates some of it). Note that this is a way to shortcut the brew qt5 with dbus installation which takes forever and instead uses the version of qt that downloads with Qt Creator. At the end, I still had to copy in the astrometry folder, the data folder, and the xplanet folder because Jamie hasn't added that to the cmake version of his script yet (but it is in the emerge version if you want to see what is needed ~ line 507 in build-kstars.sh). Or you can just do what I do, keep a copy of the stuff that needs to go into the app bundle on your desktop and whenever they disable the copying due to testing something it is right there ready to copy into the app bundle.
www.indilib.org/forum/ekos/525-ekos-on-m...tml?start=1020#12470
If it helps here is the structure of our app bundle:
The Data directory files go into /Contents/Resources/data/ and will be copied into their proper place in application support on application start if they are not there yet.
The Indi drivers and xml files all go into /Contents/MacOS/indi/ and you can just copy and paste them there from /usr/local/bin and /usr/local/share/indi .
The astrometry files all go into /Contents/MacOS/astrometry/ and what you need to copy is the bin and lib folders from the brew astrometry.net to make it work
The astrometry.cfg file goes into /Contents/MacOS/astrometry/bin/. Don't worry about the add_path variable, it will be set properly on application start and/or when you try to use the offline plate solver.
Any astrometry.net index files need to be placed into ~/Library/Application Support/Astrometry/. You can even use the Cloudmakers software to download them and install them since it uses the same location.
The xplanet files go into /Contents/MacOS/xplanet and all you need is the bin and share folders to make it work.
Your planet textures go into /Contents/MacOS/xplanet/share/xplanet/images/
GSC gets placed into the data directory in ~/Library/Application Support/kstars/
Stephane and Jamie, please correct me if I am wrong on any of this. I think I got it right. Thanks!
Time to create page: 0.248 seconds
© 2003-2020 by INDI Library. All rights reserved.