Mac OS
-
- Supporting Users
- Posts: 141
- Joined: Tue Jan 09, 2018 6:48 pm
Re: Mac OS
Jep, looks good.
Btw: cmake_minimum_required(VERSION 3.0.0) is now a global requirement anyway and can be removed.
I guess you set also the deployment target to 10.9 ( and changed my very old comment about 10.6 compat.)
Anyway, afaik xcode 8 and higher will force you to 10.9 target and c++11 afaik.
Jens
Btw: cmake_minimum_required(VERSION 3.0.0) is now a global requirement anyway and can be removed.
I guess you set also the deployment target to 10.9 ( and changed my very old comment about 10.6 compat.)
Anyway, afaik xcode 8 and higher will force you to 10.9 target and c++11 afaik.
Jens
-
- Posts: 28
- Joined: Sun Jan 28, 2018 2:10 pm
- Location: Canada
Re: Mac OS
Once I get my old MacBook Air up and running, I'll try compiling it on 10.12 Sierra.
-
- Posts: 28
- Joined: Sun Jan 28, 2018 2:10 pm
- Location: Canada
Re: Mac OS
I sat down this evening and taught myself pkgbuild and productbuild on OSX. I have some grasp and can get it to make an installer. Finding documentation is pretty tough to do much right now beyond the basics. I found a document describing all the XML, but doesn't describe the actual structure of the distribution.plist file. I've taken apart a couple existing pkg files to see how they tick with limited success.
The installer, as it stands now, installs the CLI applications into /usr/local/bin. I chose that directory as it is pretty much guaranteed to be in a user's PATH environment variable.
It also installs sample scenes into /Users/Shared/Documents/Lux
It does an intro page, icons and background image. Displays a simple welcome blurb and presents the Apache license which a user must agree to before installation continues.
Issues:
No Selective Install -- A user cannot selectively just install the CLI or scene files. Tried using and looking up the <choices-outline> and <choice> tags.
Platform and OS checking -- It's possible through scripting (Javascript or shell), and it's on the list.
Permissions -- Installer sets the user:group to the unprivileged nobody:staff. Seems to work without root permissions, and can't really see why it would ever need it, but I'm not exactly knowledgeable about any internals of the software. I think the permissions on all the scene files are root permission... will fix that.
Has anyone written a man page for either of these utilities? It could be a nice addition. I read man pages, but never made one.
I'd like to add more macOS items to the install when they are ready, like the standalone LuxRender.app and so on. A kind of one-stop shop.
Leaving the file to upload overnight. On a slow DSL connection.
The installer, as it stands now, installs the CLI applications into /usr/local/bin. I chose that directory as it is pretty much guaranteed to be in a user's PATH environment variable.
It also installs sample scenes into /Users/Shared/Documents/Lux
It does an intro page, icons and background image. Displays a simple welcome blurb and presents the Apache license which a user must agree to before installation continues.
Issues:
No Selective Install -- A user cannot selectively just install the CLI or scene files. Tried using and looking up the <choices-outline> and <choice> tags.
Platform and OS checking -- It's possible through scripting (Javascript or shell), and it's on the list.
Permissions -- Installer sets the user:group to the unprivileged nobody:staff. Seems to work without root permissions, and can't really see why it would ever need it, but I'm not exactly knowledgeable about any internals of the software. I think the permissions on all the scene files are root permission... will fix that.
Has anyone written a man page for either of these utilities? It could be a nice addition. I read man pages, but never made one.
I'd like to add more macOS items to the install when they are ready, like the standalone LuxRender.app and so on. A kind of one-stop shop.
Leaving the file to upload overnight. On a slow DSL connection.
-
- Supporting Users
- Posts: 141
- Joined: Tue Jan 09, 2018 6:48 pm
Re: Mac OS
Afaik pkgbuild is pretty much ruined nowadays, so the most devs write their own installers.
Last time i made a osx prototype i tested succesfull "packages" from a french dev. which
turned out to be a pretty nice replacement for the abandoned packagemaker.
Jens
Last time i made a osx prototype i tested succesfull "packages" from a french dev. which
turned out to be a pretty nice replacement for the abandoned packagemaker.
Jens
-
- Posts: 28
- Joined: Sun Jan 28, 2018 2:10 pm
- Location: Canada
Re: Mac OS
The new utilities are ... functional. But any customization has to be done by hand.
Think I got selectable list for custom install.
--
Using the pkg installer created on High Sierra does work on Sierra. The only thing I needed to do was include in the embree and TBB libraries and included them in the internal package for LuxCore CLI. Is there any license issue doing this?
Given the structure of .app, will LuxCoreRenderer require the libraries from /opt/local/lib or will they internalized inside the .app?
Permissions are reverting to root:wheel on installed items. Not sure why that's happening again. I made sure to chown files to nobody:staff. I can understand wy maybe the installer needs root privileges, but not why it's defaulting permissions to root:wheel. I must be missing something but can't see what.
--
Getting all sorts of missing libraries, which I should have foreseen. Looking at the old setup, the command line utilities were run from inside the LuxRender.app so looks like they used the libraries included there.
So, I guess for the installer we can wait. With the installer, though, it can run a shell script to perform the linking at install. So just get the installer to create the symlinks into /usr/local/bin at that time.
Think I got selectable list for custom install.
--
Using the pkg installer created on High Sierra does work on Sierra. The only thing I needed to do was include in the embree and TBB libraries and included them in the internal package for LuxCore CLI. Is there any license issue doing this?
Given the structure of .app, will LuxCoreRenderer require the libraries from /opt/local/lib or will they internalized inside the .app?
Permissions are reverting to root:wheel on installed items. Not sure why that's happening again. I made sure to chown files to nobody:staff. I can understand wy maybe the installer needs root privileges, but not why it's defaulting permissions to root:wheel. I must be missing something but can't see what.
--
Getting all sorts of missing libraries, which I should have foreseen. Looking at the old setup, the command line utilities were run from inside the LuxRender.app so looks like they used the libraries included there.
So, I guess for the installer we can wait. With the installer, though, it can run a shell script to perform the linking at install. So just get the installer to create the symlinks into /usr/local/bin at that time.
-
- Supporting Users
- Posts: 141
- Joined: Tue Jan 09, 2018 6:48 pm
Re: Mac OS
Otool is your friendGetting all sorts of missing libraries, which I should have foreseen. Looking at the old setup, the command line utilities were run from inside the LuxRender.app so looks like they used the libraries included there.
Also: Sure you can design luxcoreui as an appbundle. Set the guitype in the apropriate cmake file to MACOSX_BUNDLE simply.
Then deliver the needed libs in the bundle according to Apple specs. Be aware you then need to have entitlements and have
to face gatekeeper requirements. Codesigning is not yet a must afaik, but would be proposed once you go bundles.
Jens
Last edited by jensverwiebe on Wed Jan 31, 2018 10:29 pm, edited 1 time in total.
Re: Mac OS
Nope, no problem, Embree is released under APL v2.0 license like us.patrickwalker wrote: ↑Wed Jan 31, 2018 12:58 pm Using the pkg installer created on High Sierra does work on Sierra. The only thing I needed to do was include in the embree and TBB libraries and included them in the internal package for LuxCore CLI. Is there any license issue doing this?
-
- Posts: 28
- Joined: Sun Jan 28, 2018 2:10 pm
- Location: Canada
Re: Mac OS
Getting beyond my pay grade. Probably wiser for me just to wait for LuxCoreRenderer and proceed from there.jensverwiebe wrote: ↑Wed Jan 31, 2018 7:14 pmOtool is your friendGetting all sorts of missing libraries, which I should have foreseen. Looking at the old setup, the command line utilities were run from inside the LuxRender.app so looks like they used the libraries included there.
Also: Sure you can design luxcoreui as an appbundle. Set the guitype in the apropriate cmake file to MACOSX_BUNDLE simply.
Then deliver the needed libs in the bundle according to Apple specs. Be aware you then need to have entitlements and have
to face gatekeeper requirements. Codesigning is not yet a must afaik, but would be proposed once you go bundles.
Jens
I think it could be possible just to copy over /usr/local/lib at the same time luxcoreui and luxcoreconsole. But wary of doing that. Licensing and the like. Just looking at Boost libraries...
-
- Posts: 28
- Joined: Sun Jan 28, 2018 2:10 pm
- Location: Canada
Re: Mac OS
I've begun my attempt at configuring cmake and compiling LuxCore on a 10.12 Sierra system.
Some interesting notes. cmake is finding macOS header files, not in Xcode, but inside "/Library/Developer/CommandLineTools"
I've placed cl.hpp inside both Xcode and this CommandLineTools yet still Xcode cannot access the file:
Fixed that issue with a:
There's two of them in the cmake I used but I think it might have been needed earlier in the file than it was originally.
Another thing I had to do to get CMAKE to work is add in:
LuxCore compiles successfully (LuxCoreUI and LuxCoreConsole).
Here is the Config_OSX.cmake I used for both 10.12 Sierra and 10.13 High Sierra.
Some interesting notes. cmake is finding macOS header files, not in Xcode, but inside "/Library/Developer/CommandLineTools"
I've placed cl.hpp inside both Xcode and this CommandLineTools yet still Xcode cannot access the file:
Code: Select all
#include <OpenCL/cl.hpp>
Code: Select all
find_path(OPENCL_INCLUDE_DIR cl.hpp PATHS "${CMAKE_OSX_ROOT}")
Another thing I had to do to get CMAKE to work is add in:
Code: Select all
set(EMBREE_INCLUDE_PATH ${OSX_DEPENDENCY_ROOT})
Here is the Config_OSX.cmake I used for both 10.12 Sierra and 10.13 High Sierra.
Code: Select all
###########################################################################
#
# Configuration ( Jens Verwiebe )
#
###########################################################################
########## OS and hardware detection ###########
execute_process(COMMAND uname -r OUTPUT_VARIABLE MAC_SYS) # check for actual system-version
if(${MAC_SYS} MATCHES 17)
set(OSX_SYSTEM 10.13)
elseif(${MAC_SYS} MATCHES 16)
set(OSX_SYSTEM 10.12)
elseif(${MAC_SYS} MATCHES 15)
set(OSX_SYSTEM 10.11)
set(QT_BINARY_DIR /usr/local/bin) # workaround for the locked /usr/bin install Qt ti /usr/local !
elseif(${MAC_SYS} MATCHES 14)
set(OSX_SYSTEM 10.10)
elseif(${MAC_SYS} MATCHES 13)
set(OSX_SYSTEM 10.9)
elseif(${MAC_SYS} MATCHES 12)
set(OSX_SYSTEM 10.8)
elseif(${MAC_SYS} MATCHES 11)
set(OSX_SYSTEM 10.7)
elseif(${MAC_SYS} MATCHES 10)
set(OSX_SYSTEM 10.6)
else()
set(OSX_SYSTEM unsupported)
endif()
MESSAGE(STATUS "Using OSX Configuration settings")
# Allow for the location of OSX_DEPENDENCY_ROOT to be set from the command line
IF( NOT OSX_DEPENDENCY_ROOT )
set(OSX_DEPENDENCY_ROOT ${CMAKE_SOURCE_DIR}/../macos) # can be macos or usr/local for example
ENDIF()
MESSAGE(STATUS "OSX_DEPENDENCY_ROOT : " ${OSX_DEPENDENCY_ROOT})
set(OSX_SEARCH_PATH ${OSX_DEPENDENCY_ROOT})
# Libs present in system ( /usr )
SET(SYS_LIBRARIES z )
# Libs that have find_package modules
set(OPENIMAGEIO_ROOT_DIR "${OSX_SEARCH_PATH}")
set(BOOST_SEARCH_PATH "${OSX_SEARCH_PATH}")
set(BOOST_LIBRARYDIR "${BOOST_SEARCH_PATH}/lib")
# Find OpenCL Header
find_path(OPENCL_INCLUDE_DIR cl.hpp PATHS "${CMAKE_OSX_ROOT}")
# Find OpenGL Headers
find_path(OPENGL_SEARCH_PATH CGLContext.h PATHS "${CMAKE_OSX_SYSROOT}/System/Library/Frameworks/OpenGL.framework/Versions/Current/Headers" )
find_path(OPENGL_INCLUDE_PATH CGLContext.h PATHS "${CMAKE_OSX_SYSROOT}/System/Library/Frameworks/OpenGL.framework/Versions/Current/Headers" )
#find_library(GLEW_LIBRARY libGLEW.a PATHS ${OSX_SEARCH_PATH}/lib )
MESSAGE(STATUS "--------------------------------------------------------------")
set(EMBREE_INCLUDE_PATH "{OSX_DEPENDENCY_ROOT")
set(EMBREE_SEARCH_PATH "{OSX_DEPENDENCY_ROOT}")
set(GLEW_SEARCH_PATH "${OSX_SEARCH_PATH}")
find_path(GLEW_INCLUDE_DIR glew.h PATHS ${OSX_SEARCH_PATH}/include/GL )
find_library(GLEW_LIBRARY libGLEW.a PATHS ${OSX_SEARCH_PATH}/lib )
set(GLEW_FOUND 1)
set(GLUT_SEARCH_PATH "${CMAKE_OSX_SYSROOT}/System/Library/Frameworks/glut.framework")
set(GLUT_INCLUDE_PATH "${GLUT_SEARCH_PATH}/Headers")
#set(GLUT_LIBRARYDIR "${GLUT_SEARCH_PATH}")
SET(OPENEXR_ROOT "${OSX_SEARCH_PATH}")
# Libs with hardcoded pathes ( macos repo )
SET(TIFF_LIBRARIES ${OSX_DEPENDENCY_ROOT}/lib/libtiff.a)
SET(TIFF_INCLUDE_DIR ${OSX_DEPENDENCY_ROOT}/include/tiff)
SET(TIFF_FOUND ON)
SET(JPEG_LIBRARIES ${OSX_DEPENDENCY_ROOT}/lib/libjpeg.a)
SET(JPEG_INCLUDE_DIR ${OSX_DEPENDENCY_ROOT}/include/jpeg)
SET(JPEG_FOUND ON)
SET(PNG_LIBRARIES ${OSX_DEPENDENCY_ROOT}/lib/libpng.a ${SYS_LIBRARIES})
SET(PNG_INCLUDE_DIR ${OSX_DEPENDENCY_ROOT}/include/png)
SET(PNG_FOUND ON)
# use Blender python libs for static compiling !
SET(PYTHON_LIBRARIES ${OSX_DEPENDENCY_ROOT}/lib/BF_pythonlibs/py34_intel64/libbf_python_ext.a ${OSX_DEPENDENCY_ROOT}/lib/BF_pythonlibs/py34_intel64/libbf_python.a)
SET(PYTHON_INCLUDE_DIRS ${OSX_DEPENDENCY_ROOT}/include/Python3.4m)
SET(PYTHONLIBS_FOUND ON)
Last edited by patrickwalker on Sun Feb 04, 2018 3:14 pm, edited 1 time in total.
-
- Supporting Users
- Posts: 141
- Joined: Tue Jan 09, 2018 6:48 pm
Re: Mac OS
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
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