New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#595 Fix build of the SFML target on OS X with Xcode #596

Merged
merged 1 commit into from May 13, 2014

Conversation

Projects
None yet
5 participants
@Ceylo
Contributor

Ceylo commented May 12, 2014

This fixes the build issues for the SFML target with Xcode without breaking builds with Unix Makefile.

@Ceylo

This comment has been minimized.

Show comment
Hide comment
@Ceylo

Ceylo May 12, 2014

Contributor

Related to issue #595

Contributor

Ceylo commented May 12, 2014

Related to issue #595

@eXpl0it3r eXpl0it3r added OS X labels May 13, 2014

@eXpl0it3r eXpl0it3r added this to the 2.2 milestone May 13, 2014

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini May 13, 2014

Member

I can merge this, sure, but it doesn't mean SFML supports Xcode generator; there are too many subtleties with it... sometimes it works, sometimes it doesn't, depending on Xcode version and so many other factors.

Member

mantognini commented May 13, 2014

I can merge this, sure, but it doesn't mean SFML supports Xcode generator; there are too many subtleties with it... sometimes it works, sometimes it doesn't, depending on Xcode version and so many other factors.

mantognini added a commit that referenced this pull request May 13, 2014

Merge pull request #596 from Ceylo/bugfix/595_OSXFrameworkCreation
#595 Fix build of the SFML target on OS X with Xcode

Nevertheless, Xcode generator is not officially supported by SFML

@mantognini mantognini merged commit 44a192d into SFML:master May 13, 2014

@mantognini mantognini added the resolved label May 13, 2014

@Ceylo

This comment has been minimized.

Show comment
Hide comment
@Ceylo

Ceylo May 14, 2014

Contributor

What doesn't work? So if I understand correctly you can't fully support the main generator on OS X?

Contributor

Ceylo commented May 14, 2014

What doesn't work? So if I understand correctly you can't fully support the main generator on OS X?

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini May 14, 2014

Member

It really depends on your environment. One example: in #594 it appears Xcode can't install SFML properly unless you chmod a+w your Frameworks folder... and since Apple update its tools without letting dev know what changed there is no guarantee it will work any better in the future.

Member

mantognini commented May 14, 2014

It really depends on your environment. One example: in #594 it appears Xcode can't install SFML properly unless you chmod a+w your Frameworks folder... and since Apple update its tools without letting dev know what changed there is no guarantee it will work any better in the future.

@Ceylo

This comment has been minimized.

Show comment
Hide comment
@Ceylo

Ceylo May 14, 2014

Contributor

Well to me it doesn't make sense for the Frameworks directory to be writable by anyone. It would allow replacing frameworks with malicious ones by anyone. So it is really normal to require either permission changes or running Xcode as root. If I'm not mistaken that's just the same on Linux and Windows. You can't run make install without using sudo and you can't install files on Windows from Visual Studio without running it as admin.

I think you are trying to rely on something wrong.

Contributor

Ceylo commented May 14, 2014

Well to me it doesn't make sense for the Frameworks directory to be writable by anyone. It would allow replacing frameworks with malicious ones by anyone. So it is really normal to require either permission changes or running Xcode as root. If I'm not mistaken that's just the same on Linux and Windows. You can't run make install without using sudo and you can't install files on Windows from Visual Studio without running it as admin.

I think you are trying to rely on something wrong.

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini May 14, 2014

Member

You misunderstood me. That's exactly why I don't support Xcode generator (which I wouldn't call the «main» generator on OS X). Running Xcode as superuser is no better than chmod'ing Library. Creating a new file, saving preferences, ... all that can lead to problem later since we don't know what's happening under the hood. And beside that rights issue, as I said before, we never know when it will stop working. On the other hand, I'm pretty confident that with Makefile we won't have any compatibility problem in the near future.

Member

mantognini commented May 14, 2014

You misunderstood me. That's exactly why I don't support Xcode generator (which I wouldn't call the «main» generator on OS X). Running Xcode as superuser is no better than chmod'ing Library. Creating a new file, saving preferences, ... all that can lead to problem later since we don't know what's happening under the hood. And beside that rights issue, as I said before, we never know when it will stop working. On the other hand, I'm pretty confident that with Makefile we won't have any compatibility problem in the near future.

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila May 14, 2014

Member

It seems like the issue you describe has more to do with the install location than with the generator itself. Even a makefile will require admin rights to install libraries into a system directory, right? On the other hand, installing SFML to a home directory should never require admin rights, regardless of the generator.

Member

LaurentGomila commented May 14, 2014

It seems like the issue you describe has more to do with the install location than with the generator itself. Even a makefile will require admin rights to install libraries into a system directory, right? On the other hand, installing SFML to a home directory should never require admin rights, regardless of the generator.

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini May 14, 2014

Member

That's one of the issue I've met. There was others I think – I don't remember all the details, it was a few years back already.

If someone else want to officially support Xcode generator I'm okay with that. But I would rather not be bald at 30 because I spent too much time making things work just for "that" (using makefile to build SFML is not bad). ;-)

Member

mantognini commented May 14, 2014

That's one of the issue I've met. There was others I think – I don't remember all the details, it was a few years back already.

If someone else want to officially support Xcode generator I'm okay with that. But I would rather not be bald at 30 because I spent too much time making things work just for "that" (using makefile to build SFML is not bad). ;-)

@MarioLiebisch

This comment has been minimized.

Show comment
Hide comment
@MarioLiebisch

MarioLiebisch May 14, 2014

Member

Yep, it's based on the paths chosen by the user and the system. It's nothing the build system should force, unless it's really something that's standardized. But different question: If the CMake script is able to set permissions, shouldn't it have regular file access anyway, i.e. not requiring different access rights?

Member

MarioLiebisch commented May 14, 2014

Yep, it's based on the paths chosen by the user and the system. It's nothing the build system should force, unless it's really something that's standardized. But different question: If the CMake script is able to set permissions, shouldn't it have regular file access anyway, i.e. not requiring different access rights?

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini May 14, 2014

Member

If the CMake script is able to set permissions, shouldn't it have regular file access anyway?

CMake does not change any permission.

Member

mantognini commented May 14, 2014

If the CMake script is able to set permissions, shouldn't it have regular file access anyway?

CMake does not change any permission.

@Ceylo

This comment has been minimized.

Show comment
Hide comment
@Ceylo

Ceylo May 14, 2014

Contributor

CMake does not change any permission.

In any case it could not, because the user does not own the directory and doesn't have enough permissions to change the permissions.

And beside that rights issue, as I said before, we never know when it will stop working.

What are you specifically talking of here with "it"?
It's the work of CMake developers to keep their solution compatible with the evolution of OS X and Xcode. You of course don't have to do their job.

As for the password issue, what could eventually be done is creating a CMake target that runs the "install" target as root, with a graphical prompt for the user. This allows running the target with higher permissions and doesn't require to launch Xcode as root.

To get a bit more into details, create a custom CMake target that invokes xcodebuild through osascript. osascript is the AppleScript interpreter, and you can ask for a graphical password prompt to run some command like osascript -e "do shell script \"xcodebuild -project SFML.xcodeproj -target install\" with administrator privileges" and that could do the trick.

Contributor

Ceylo commented May 14, 2014

CMake does not change any permission.

In any case it could not, because the user does not own the directory and doesn't have enough permissions to change the permissions.

And beside that rights issue, as I said before, we never know when it will stop working.

What are you specifically talking of here with "it"?
It's the work of CMake developers to keep their solution compatible with the evolution of OS X and Xcode. You of course don't have to do their job.

As for the password issue, what could eventually be done is creating a CMake target that runs the "install" target as root, with a graphical prompt for the user. This allows running the target with higher permissions and doesn't require to launch Xcode as root.

To get a bit more into details, create a custom CMake target that invokes xcodebuild through osascript. osascript is the AppleScript interpreter, and you can ask for a graphical password prompt to run some command like osascript -e "do shell script \"xcodebuild -project SFML.xcodeproj -target install\" with administrator privileges" and that could do the trick.

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini May 14, 2014

Member

What are you specifically talking of here with "it"?
It's the work of CMake developers to keep their solution compatible with the evolution of OS X and Xcode. You of course don't have to do their job.

I was referencing the SFML build process & its installation. Yes, it's not up to me to make it work BUT it's up to SFML team (and thus me among others) to say to the user "We don't know why it's not working". It just opens a door to frustration.

As for the password issue, what could eventually be done is creating a CMake target that runs the "install" target as root, with a graphical prompt for the user. This allows running the target with higher permissions and doesn't require to launch Xcode as root.

So much pain for pretty much nothing. I don't see the benefit of updating the whole cmake script just to make it work for one extra generator when make is enough and works for everyone.

I would rather spend my time on improving the actual interesting part of this project: SFML, not its build system. ;-)

Member

mantognini commented May 14, 2014

What are you specifically talking of here with "it"?
It's the work of CMake developers to keep their solution compatible with the evolution of OS X and Xcode. You of course don't have to do their job.

I was referencing the SFML build process & its installation. Yes, it's not up to me to make it work BUT it's up to SFML team (and thus me among others) to say to the user "We don't know why it's not working". It just opens a door to frustration.

As for the password issue, what could eventually be done is creating a CMake target that runs the "install" target as root, with a graphical prompt for the user. This allows running the target with higher permissions and doesn't require to launch Xcode as root.

So much pain for pretty much nothing. I don't see the benefit of updating the whole cmake script just to make it work for one extra generator when make is enough and works for everyone.

I would rather spend my time on improving the actual interesting part of this project: SFML, not its build system. ;-)

@Ceylo

This comment has been minimized.

Show comment
Hide comment
@Ceylo

Ceylo May 14, 2014

Contributor

So much pain for pretty much nothing.

Depends on the point of view. I wouldn't call a working solution for Xcode 'pretty much nothing'.

I don't see the benefit of updating the whole cmake script just to make it work for one extra generator when make is enough and works for everyone.

Well with such argument GUI would not exist yet :)
SFML has the word simple in it, which means beginners will come and try to use SFML. With this argument you're hardening the path to the use of up-to-date SFML versions for them. I agree running sudo make isn't like climbing a mountain though. So it depends on up to which way you want to simplify the task for users. I don't know the position of the SFML team about this.

I would rather spend my time on improving the actual interesting part of this project: SFML, not its build system. ;-)

I completely agree with spending more time on working on the interesting part. However I disagree with the fact that the build system is not interesting. It's indeed not the most interesting from the developer's point of view, but what's the point of adding features if less people benefit from them?

Contributor

Ceylo commented May 14, 2014

So much pain for pretty much nothing.

Depends on the point of view. I wouldn't call a working solution for Xcode 'pretty much nothing'.

I don't see the benefit of updating the whole cmake script just to make it work for one extra generator when make is enough and works for everyone.

Well with such argument GUI would not exist yet :)
SFML has the word simple in it, which means beginners will come and try to use SFML. With this argument you're hardening the path to the use of up-to-date SFML versions for them. I agree running sudo make isn't like climbing a mountain though. So it depends on up to which way you want to simplify the task for users. I don't know the position of the SFML team about this.

I would rather spend my time on improving the actual interesting part of this project: SFML, not its build system. ;-)

I completely agree with spending more time on working on the interesting part. However I disagree with the fact that the build system is not interesting. It's indeed not the most interesting from the developer's point of view, but what's the point of adding features if less people benefit from them?

@mantognini

This comment has been minimized.

Show comment
Hide comment
@mantognini

mantognini May 14, 2014

Member

I wouldn't call a working solution for Xcode 'pretty much nothing'.

It's a matter of perspective, sure, but between cmake; make; make install and cmake; click; click in GUI... the former is so simple that I don't see any added value to the second one except "look, it also work in Xcode". For a lambda user, the installation process is not common. Using Xcode (or whatever other tool for that matter) instead of Makefile won't increase one's productivity.

Well with such argument GUI would not exist yet :)

It feels strange to hear that when working on a multimedia library. You know that my point wasn't to use vi in an archaic terminal and never use a mouse except to feed your snake (or cat). ;-)

SFML has the word simple in it, which means beginners will come and try to use SFML. With this argument you're hardening the path to the use of up-to-date SFML versions for them.

Well, if one cannot read the cmake tutorial – which is really good for noobies I think – and cannot write on the forum when he/she has some trouble, plus the fact that we provide compiled binaries ready to be used, I'm not sure this person will be able to write a multimedia app at all. For me, this kind of developer is not in the scope of SFML.

what's the point of adding features if less people benefit from them?

What do you mean by «less people»?

Member

mantognini commented May 14, 2014

I wouldn't call a working solution for Xcode 'pretty much nothing'.

It's a matter of perspective, sure, but between cmake; make; make install and cmake; click; click in GUI... the former is so simple that I don't see any added value to the second one except "look, it also work in Xcode". For a lambda user, the installation process is not common. Using Xcode (or whatever other tool for that matter) instead of Makefile won't increase one's productivity.

Well with such argument GUI would not exist yet :)

It feels strange to hear that when working on a multimedia library. You know that my point wasn't to use vi in an archaic terminal and never use a mouse except to feed your snake (or cat). ;-)

SFML has the word simple in it, which means beginners will come and try to use SFML. With this argument you're hardening the path to the use of up-to-date SFML versions for them.

Well, if one cannot read the cmake tutorial – which is really good for noobies I think – and cannot write on the forum when he/she has some trouble, plus the fact that we provide compiled binaries ready to be used, I'm not sure this person will be able to write a multimedia app at all. For me, this kind of developer is not in the scope of SFML.

what's the point of adding features if less people benefit from them?

What do you mean by «less people»?

@Ceylo

This comment has been minimized.

Show comment
Hide comment
@Ceylo

Ceylo May 14, 2014

Contributor

For me, this kind of developer is not in the scope of SFML.

Ok, well then that's all there is to say :)

what's the point of adding features if less people benefit from them?
What do you mean by «less people»?

I targetted these people that are not in SFML's scope.

One last point about Xcode though: I would have liked to see at least a warning when using CMake with this generator. I didn't read the tutorial and I expected CMake to work just fine. If the Xcode generator isn't fully supported, this should at least be told to the user (especially the one used to CMake and who expects it to just work fine).

Contributor

Ceylo commented May 14, 2014

For me, this kind of developer is not in the scope of SFML.

Ok, well then that's all there is to say :)

what's the point of adding features if less people benefit from them?
What do you mean by «less people»?

I targetted these people that are not in SFML's scope.

One last point about Xcode though: I would have liked to see at least a warning when using CMake with this generator. I didn't read the tutorial and I expected CMake to work just fine. If the Xcode generator isn't fully supported, this should at least be told to the user (especially the one used to CMake and who expects it to just work fine).

@Ceylo Ceylo deleted the Ceylo:bugfix/595_OSXFrameworkCreation branch Dec 29, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment