macOS make install fails when run with ExternalProject_Add()

[Gonzalo Garramuno]

When running the compilation of fltk thru ExternalProject_Add() cmake will try to install fluid into the /Applications/ directory and it will fail due to lack of permissions unless run as root user.

-- Up-to-date: /Applications/fluid.app
CMake Error at fluid/cmake_install.cmake:49 (file):
file INSTALL cannot set permissions on "/Applications/fluid.app": Operation
not permitted.
Call Stack (most recent call first):
cmake_install.cmake:105 (include)

The ExternalProject_Add() looks like:

Include( ExternalProject )

ExternalProject_Add(
FLTK
GIT_REPOSITORY "https://github.com/fltk/fltk.git"
GIT_PROGRESS 1
CMAKE_ARGS
-DCMAKE_MODULE_PATH=${CMAKE_MODULE_PATH}
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
-DCMAKE_PREFIX_PATH=${CMAKE_INSTALL_PREFIX}
-DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-DCMAKE_C_FLAGS=${CMAKE_C_FLAGS}
-DCMAKE_CXX_FLAGS=${CMAKE_CXX_FLAGS}
-DFLTK_BUILD_EXAMPLES=OFF
-DFLTK_BUILD_TEST=OFF
-DOPTION_BUILD_SHARED_LIBS=0
-DOPTION_USE_SYSTEM_ZLIB=0
-DOPTION_USE_SYSTEM_LIBJPEG=0
-DOPTION_USE_SYSTEM_LIBPNG=0
)


—
Gonzalo Garramuno
ggar...@gmail.com

[Albrecht Schlosser]

On 8/13/22 13:23 Gonzalo Garramuno wrote:
> When running the compilation of fltk thru ExternalProject_Add() cmake will try to install fluid into the /Applications/ directory and it will fail due to lack of permissions unless run as root user.
>
> -- Up-to-date: /Applications/fluid.app
> CMake Error at fluid/cmake_install.cmake:49 (file):
> file INSTALL cannot set permissions on "/Applications/fluid.app": Operation
> not permitted.
> Call Stack (most recent call first):
> cmake_install.cmake:105 (include)

OK, I understand the words, but I believe we need more context. What
exactly are the steps you do when this happens? Could you please provide
a full CMakeLists.txt with a demo (hello world) file that uses this
technique and describe the commands you use so we (I) can test?

> The ExternalProject_Add() looks like:
>
> Include( ExternalProject )
>
> ExternalProject_Add(
> FLTK
> GIT_REPOSITORY "https://github.com/fltk/fltk.git"
> GIT_PROGRESS 1
> CMAKE_ARGS
> -DCMAKE_MODULE_PATH=${CMAKE_MODULE_PATH}
> -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
> -DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}

The above statement is, if I'm not missing anything, redundant. It sets
the FLTK install prefix to that of your main CMake invocation. If this
is '/Applications' then it is correct for FLTK to be installed in that
location and you need the corresponding privileges whenever the built
FLTK project is installed.

What am I missing?

> -DCMAKE_PREFIX_PATH=${CMAKE_INSTALL_PREFIX}

I'm also not sure if this (above) is a valid (useful) assignment. Can
you explain why this is done?

[Gonzalo Garramuño]

On 13/8/22 10:01, Albrecht Schlosser wrote:
> On 8/13/22 13:23 Gonzalo Garramuno wrote:
>> When running the compilation of fltk thru ExternalProject_Add() cmake
>> will try to install fluid into the /Applications/ directory and it
>> will fail due to lack of permissions unless run as root user.
>>
>> -- Up-to-date: /Applications/fluid.app
>> CMake Error at fluid/cmake_install.cmake:49 (file):
>>    file INSTALL cannot set permissions on "/Applications/fluid.app":
>> Operation
>>    not permitted.
>> Call Stack (most recent call first):
>>    cmake_install.cmake:105 (include)
>
> OK, I understand the words, but I believe we need more context. What
> exactly are the steps you do when this happens? Could you please
> provide a full CMakeLists.txt with a demo (hello world) file that uses
> this technique and describe the commands you use so we (I) can test?

CMakeLists.txt
---------------------

cmake_minimum_required(VERSION 3.10)

# Use extraction timestamps
if( NOT CMAKE_VERSION LESS 3.24.0 )
  cmake_policy( SET CMP0135 NEW )
endif()

#
# Run this file by calling runme.sh - NOT cmake
#
project( Dependencies )


# use, i.e. don't skip the full RPATH for the build tree
SET(CMAKE_SKIP_BUILD_RPATH FALSE)

# when building, don't use the install RPATH already
# (but later on when installing)
SET(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)

# the RPATH to be used when installing
SET(CMAKE_INSTALL_RPATH "")


set( CMAKE_MAKEFILE_VERBOSE 1 )

# Many Build Libraries here, then we get to:

include( BuildFLTK.cmake )

BuildFLTK.cmake
------------------------

Include( ExternalProject )

ExternalProject_Add(
   FLTK
   GIT_REPOSITORY "https://github.com/fltk/fltk.git"
   GIT_PROGRESS 1
   CMAKE_ARGS
  -DCMAKE_MODULE_PATH=${CMAKE_MODULE_PATH}
  -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
  -DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}

# this is done, in case fltk looks for libraries like libcairo which was
compiled previously and installed in
# INSTALL_PREFIX.
  -DCMAKE_PREFIX_PATH=${CMAKE_INSTALL_PREFIX}

  -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
  -DCMAKE_C_FLAGS=${CMAKE_C_FLAGS}
  -DCMAKE_CXX_FLAGS=${CMAKE_CXX_FLAGS}
  -DFLTK_BUILD_EXAMPLES=OFF
  -DFLTK_BUILD_TEST=OFF
  -DOPTION_BUILD_SHARED_LIBS=0
  -DOPTION_USE_SYSTEM_ZLIB=0
  -DOPTION_USE_SYSTEM_LIBJPEG=0
  -DOPTION_USE_SYSTEM_LIBPNG=0)

I call cmake, with:

cmake .. -DCMAKE_INSTALL_PREFIX=$PWD/install

The problem is that while it works fine on Windows and Linux on macOS
the INSTALL_PREFIX is not respected and fluid is dumped into
Applications directly, instead of in $PWD/install/bin.

--
Gonzalo Garramuño
ggar...@gmail.com

[Rob McDonald]

I build FLTK through ExternalProject_Add() on Windows and MacOS regularly.  My setup is here...

https://github.com/OpenVSP/OpenVSP/blob/main/Libraries/cmake/External_FLTK.cmake

Rob

[Gonzalo Garramuño]

On 13/8/22 12:20, Rob McDonald wrote:
> I build FLTK through ExternalProject_Add() on Windows and MacOS
> regularly.  My setup is here...
>
> https://github.com/OpenVSP/OpenVSP/blob/main/Libraries/cmake/External_FLTK.cmake
>
> Rob
>

Is this fltk1.3 or 1.4?

--
Gonzalo Garramuño
ggar...@gmail.com

[Rob McDonald]

I have used the same ExternalProject_Add() setup with many versions both 1.3 and 1.4.

Rather than fetch from fltk's git, I use a *.zip file included in my project git repository.  I name that file after the SHA in the FLTK repo.  Consequently, this code currently references

https://github.com/fltk/fltk/commit/47ba6632b1be

Rob

[Albrecht Schlosser]

On 8/14/22 07:00 Rob McDonald wrote:

I have used the same ExternalProject_Add() setup with many versions both 1.3 and 1.4.

Rather than fetch from fltk's git, I use a *.zip file included in my project git repository.  I name that file after the SHA in the FLTK repo.  Consequently, this code currently references

https://github.com/fltk/fltk/commit/47ba6632b1be

OK, thanks for all input, @Rob and @Gonzalo.

I believe the culprit is:

commit 14ae784f7fe08b8c051e2109a8325b671a8e1b23
Author: Matthias Melcher <...>
Date:   Sat Jan 1 13:53:21 2022 +0100

    Installing Fluid correctly on macOS


The commit Rob is using is older than the one above:

commit 47ba6632b1be5ab7f28726735fc7789916191ca7
Author: ManoloFLTK <...>
Date:   Thu May 27 08:49:12 2021 +0200

     macOS: Avoid premature FL_RELEASE event at start of drag-n-drop operation.
    

Rob, could you please test with 14ae784f7fe0 or with current master? Thanks in advance.


Gonzalo, since you are using the current version, can you please test with 14ae784f7fe08 and with the one before that one:

$ git log -1 14ae784f7fe08b8^
commit eeb3e92eb29c4fdbcdc0b0276753c1d32210a8e5
Author: ManoloFLTK <...>
Date:   Wed Dec 29 17:18:12 2021 +0100

     Fix fullscreen window level corner cases on macOS - cont'd

Before I try to fix this I'd appreciate if at least one of you could confirm that 14ae784f7fe08 is indeed the culprit. I will also try to reproduce the issue with Gonzalo's CMake script but this may take a while, please don't hold your breath. Gonzalo, thank you particularly for that as well.

That said, according to the code I saw it looks very much like the change Matt introduced ignores CMAKE_INSTALL_PREFIX which would be a bug. We need to find a way to implement the gist of Matt's change w/o ignoring CMAKE_INSTALL_PREFIX.

[Gonzalo Garramuno]

> El 14 ago. 2022, a las 07:24, Albrecht Schlosser <Albrech...@online.de> escribió:
>
> Before I try to fix this I'd appreciate if at least one of you could confirm that 14ae784f7fe08 is indeed the culprit. I will also try to reproduce the issue with Gonzalo's CMake script but this may take a while, please don't hold your breath. Gonzalo, thank you particularly for that as well.
>

I can confirm that 14ae784f7fe08 is the culprit. The previous commit compiles and installs just fine.

—
Gonzalo Garramuno
ggar...@gmail.com

[Albrecht Schlosser]

Thank you very much for testing and confirmation.

I'm currently too busy with other FLTK stuff. Please open an issue [1]
with a short description that refers to this thread so it doesn't get
lost. Thanks.

[1] https://groups.google.com/g/fltkcoredev/c/tYhruYzyu88/m/GlHTBkvABgAJ

[imacarthur]

As a slight aside - is the implication of this that our cmake script is attempting to install stuff into a "system" location?

I'm not sure how good an idea I think that is... doesn't sound like a great idea to me, at any rate...

[Albrecht Schlosser]

On 8/16/22 10:34 imacarthur wrote:

As a slight aside - is the implication of this that our cmake script is attempting to install stuff into a "system" location?

I'm not sure how good an idea I think that is... doesn't sound like a great idea to me, at any rate...

Ian, our CMake script *must* honor the install location given by the user - or if they don't do it explicitly, then use the CMake default which is very likely a system location, like  '/Applications'  on macOS and IIRC '/usr/local'  on Linux.

The issue mentioned in this thread is that the macOS CMake script ignores the user setting and *always* installs in the system location due to a change done in the commit mentioned previously in this thread. This (ignoring user settings) is a bug and I'll try to fix this, but installing in a system location is not an issue per se.

It might not be a "good idea" for some reasons (which I know about) but that's another topic.

[melcher....@googlemail.com]

Sorry, I was hoping to improve the previous setup, which had its own issues. But I understand how my solution is not perfect either. In the old setup, we would install the `Fluid.app` directory in the `install` path, but not the `fluid` binary. It would instead link into the `Fluid.app` subdirectory structure, IIRC. This did often not work for shell scripts. Omitting `/Applications/Fluid.app` if a custom install path is given is probably the right thing to do here. Not sure if `Fluid.app` should then go into the custom install path somewhere instead.