Am Sonntag, 5. Juni 2016 um 12:27:52, schrieb Stephan Witt <st.w...@gmx.net> > Am 05.06.2016 um 11:13 schrieb Georg Baum <georg.b...@post.rwth-aachen.de>: > > > > Scott Kostyshak wrote: > > > >> On Sat, Jun 04, 2016 at 07:55:28PM +0200, Stephan Witt wrote: > >>> > >>>> Am 04.06.2016 um 10:15 schrieb Liviu Andronic <landronim...@gmail.com>: > >>>> > >>>> If moving to cmake definitively would imply losing version suffix > >>>> functionality, this would be a big issue for my packaging arrangements > >>>> for Ubuntu builds. > >>> > >>> +1 > >>> > >>> On Mac the version suffix is essential too. > >> > >> I just want to make sure you saw Kornel's reply to that. I don't know if > >> it addresses your needs or not. > > > > IMHO it does. Livius builds could be done using their current names if the > > boolean switch is replaced by a string version, which is easy to do as > > Kornel wrote. > > Yes. I think so. > > > > >>> I just tried to build a Mac application with cmake and failed. > >> > >> What was the error? > >> > >>> It looks like a lot of work or to learn to make this working.
Yes. Stephan could you send me the list of installed files if you install with
automake?
I can try to use the same directories.
> >> This might be a reason to stop this discussion here. You already do a
> >> huge favor by taking care of the Mac builds. It would not make sense to
> >> make it more difficult. I was hoping that in the long-run it would
> >> actually be easier for you, but perhaps the transition would be too
> >> frustrating and time-consuming.
> >
> > We should not yet stop the discussion. We need more information about the
> > problems.
>
> I didn’t want to put the discussion on hold. I hadn’t the time to write
> a mail with enough details at the moment.
>
> I use cmake to create Xcode projects for debugging purpose. So, it’s possible
> to create a working binary with cmake. To do the packaging with cmake is
> another
> story and - at least on Mac - not done with LyX yet. No surprise it’s not
> working though.
>
> The packaging is done in three steps with autotools + scripts:
> 1. make install with the appropriate directory structure for Mac
> 2. adding the 3rd party components required to run LyX
> 3. create a mountable disk image and put the LyX app and some
> decorative stuff there and compress the final result.
>
> To get the first impression how difficult it is with cmake I tried two ways:
> 1. standard cmake install (the naive way) results in a Linux like directory
> structure without an usable application.
> 2. LYX_DMG=ON cmake install (marked as experimental) is better as it copies
> the components of LyX to the appropriate directory structure for Mac.
> Therefore the 2nd one should be the default on Mac.
>
> Nevertheless it doesn’t work ATM because of the type of the dependency on Qt.
> This is not easy to explain - but I’ll try it.
>
> The runtime linker knows of the usual LD_LIBRARY_PATH mechanism like Unix.
> An more secure and more advanced approach is the modified RPATH mechanism.
> For system libraries one uses hard coded library references.
>
> The problem is the RPATH mechanism. Qt frameworks (a collection of header
> files, shared libraries and documentation) are build with these. To distribute
> these frameworks they have to be placed on a fixed location for system wide
> use
> or inside the LyX application as so called private frameworks. LyX is using
> the latter and I cannot see why this should be changed. The cmake build
> for LyX needs to be extended to copy the Qt libraries into the LyX application
> in or before the „fixup_bundle“ phase of the packaging step. I’m almost sure
> this can be done in a reliable and clean way with cmake. That’s why I said
> there is something to learn and to spend some time with.
Sorry, you are on your own here I suppose. For me the MAC is a mystery.
> Finally I want to add the concrete error log - it ends with:
> ===============
> -- fixup_bundle: preparing…
> ...
> -- warning: gp_resolved_file_type non-absolute file
> '@rpath/QtCore.framework/Versions/5/QtCore' returning type 'other' --
> possibly incorrect
>
> possible problems:
> need more directories?
> need to use InstallRequiredSystemLibraries?
> run in install tree instead of build tree?
>
> warning: target '@rpath/QtGui.framework/Versions/5/QtGui' is not absolute...
> warning: target '@rpath/QtGui.framework/Versions/5/QtGui' does not exist...
Don't know if this helps, but I never use relative path with cmake.
#mkdir some_build_path
# cd some_build_path
# cmake abs_path_to_lyx_sources ...
> CMake Error at /opt/local/share/cmake-3.4/Modules/GetPrerequisites.cmake:800
> (message):
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolc
> hain/usr/bin/otool failed: 1
>
> error:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolc
> hain/usr/bin/otool: can't open file:
> @rpath/QtGui.framework/Versions/5/QtGui (No such file or directory)
>
> Call Stack (most recent call first):
> /opt/local/share/cmake-3.4/Modules/GetPrerequisites.cmake:925
> (get_prerequisites)
> /opt/local/share/cmake-3.4/Modules/BundleUtilities.cmake:555
> (get_prerequisites)
> /opt/local/share/cmake-3.4/Modules/BundleUtilities.cmake:804
> (get_bundle_keys) development/cmake/post_install/cmake_install.cmake:52
> (fixup_bundle) cmake_install.cmake:2703 (include)
>
> make: *** [install_buildpart_0] Error 1
>
> ================
>
> I tried to find a log file of the build but didn’t find any.
You mean from cmake? Have you tried "--debug-output" as cmake parameter?
Kornel
signature.asc
Description: This is a digitally signed message part.
