jensverwiebe wrote: ↑Sun Feb 04, 2018 1:31 pm
Thats all still odd, cause i don't need any of these tweaks to config/generate/compile.
Something must go wrong for you with the sdk setup initially.
Btw: SET(EMBREE_FOUND ON) can be commented as well cause the findmodule now works.
I only used it with hardcoded pathes to satisfy findmodules eventuallly.
Jens
Updated the cmake in the previous post.
Plopped this updated cmake back on my High Sierra machine (I think I finally killed my Sierra computer last night) and it works for alpha3 without any hiccup.
Turns out my PSU for my old MacBook Air (10.12) was dead. Seems to work fine now, though I haven't tried compiling alpha6 on it yet.
I tried compiling 2.0a6 on my iMac (10.13.3) and it fails at link.
Warns that libstdc++ is deprecated in favour of libc++ now but tells me that macos is missing lib/Debug directory. Has the macos set of files been altered, and if so, I can't seem to find that link again. Creating the lib/Debug directory only clears the warning and link errors remain. I don't know if there are files in that folder that 2.0a6 is looking for or if the existing files in the macos file archive has been changed.
I updated the Embree version to 3.0. Not sure how to copy what's necessary into macos folder or really how to force cmake or linker to use installed files.
patrickwalker wrote: ↑Thu Mar 08, 2018 8:44 pm
I updated the Embree version to 3.0. Not sure how to copy what's necessary into macos folder or really how to force cmake or linker to use installed files.
Hi,
I tried to compile LuxCore in macOS and unsurprising got problems. First I checked that the old version of Luxrays compiles ok. Then I updated the necessary libraries from the blender-darwin and tried to compile the master branch of LuxCore. I used the Config_OSX.cmake published in this thread. All libraries were found except openCL and the compilation started. It stoped with 2 errors like this:
LuxCore-master/src/slg/film/imagepipeline/plugins/bcddenoiser.cpp:213:29: error:
no viable constructor copying variable of type 'unique_ptr<bcd::IDenoiser>'
unique_ptr<bcd::IDenoiser> denoiser = nullptr;
My own efforts involve using the old bitbucket macOS dependencies folder, updated with the Windows compile deps for Luxcore. By adding cl.hpp 1.2.7 to the Xcode MacOS SDK's OpenCL framework, resolving any OpenCL issues. When compiling the Master Branch, I avoided the config from this thread as it was not needed. Otherwise it compiles like a charm in Xcode when compiled under gnu++14 and libc++, leaving only memory issues when running any of the binaries. The issue with luxcoreconsole is: Thread 1: EXC_BAD_ACCESS (code=1, address=0xfffffffffffffff0), and other similar memory issues pop up, with this line causing my issues for now: YY_CURRENT_BUFFER_LVALUE = new_buffer; in luxlex.cpp.
I managed to get it to compile on 10.12 without OpenCL so far, mainly for simplicity on getting it running.
Reconstructing the LinuxCompile build script for making the required MacOS dependencies, then made some basic changes to the Platform and Config_OSX cmake files and a nasty looking cmake call got it working. There is some weirdness with linking to some of the libraries like OpenImageIO and OpenMP so I need to clean that up before pushing something to GitHub. Also had to do some mac brew install stuff for a newer version of bison and cmake so need to sort that out as well.
My plan is to get a repo made for constructing the mac dependencies and then fork LuxCore once I get some of the oddities cleaned up.
Now that I have it building on a fork in TravisCI I have a few questions before submitting a Pull Request.
What 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.
It 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?
As 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? Travis dumps to an S3 somewhere (probably costly for a free project) for Artifacts to be globed, opt to move towards App Store delivery and see if it's possible to wrap that into Travis CI on Release process?