I have sincerely no idea of the current status of OS X versions, etc. It is up to you (at the end of the day, in open source projects, who writes the code, takes the decisions).robbrown wrote: ↑Sun Sep 09, 2018 7:48 pmWhat versions of OS X do we want to support? I don't recommend we go back to 10.6 as was before due to updates of libraries like boost. Seems like 10.10 is maybe the oldest we should go since that's the oldest TravisCI has unless there's a solid reason for something older.
I used a separated LinuxCompileDeps repository because LinuxCompile script just download a .tar.gz from LinuxCompileDeps releases. The repository is only for developers (you don't need a clone of LinuxCompileDeps to run LinuxCompile building scripts). Storing (large) binaries on GitHub is also a bit tricky (i.e. Git LFS). I did about the same for Windows.robbrown wrote: ↑Sun Sep 09, 2018 7:48 pmIt looks like the Linux and Windows Deps uses two repos, I made a single one for Mac because that's what the bitbucket version had. I opted to use the build scripts and tar.gz artifacts method the LinuxCompileDeps did for Travis builds, is there a specific need for two Deps repos in the new Lux Core builds? Also how best to handle a pull request of a whole new repo?
I guess you can follow the same pattern for MacOs but it is up to you.
If you are interested in maintaining the MacOS version, I can create the new empty repositories for MacOS on GitHUB and give you access (if you give me your GitHUB name).
The platform binary maintainers usually build a release on their PC and post the packed binaries under the release of LuxCore repository for stand alone executables and BlendLuxCore for the Blender version.robbrown wrote: ↑Sun Sep 09, 2018 7:48 pmAs far as output artifacts, currently it's just building the binaries and libraries in the build directory. I see the BitBucket one made Mac OS Applications, and Mac OS Install Packages. I'm assuming we want those, the bigger question is how and where. Maintainer builds Mac OS version on a local server and puts them in GitHub release?
It may be possible but TravisCI VMs have a long list of limitations, it is practically impossible to build a complete OpenCL version in the time limit available. So we are just handling the releases by hands (at the end of the day is just 1-2 stable releases and 6-7 alpha/beta per year).