Skip to content
This repository has been archived by the owner on Jun 25, 2020. It is now read-only.

make app package on OS X #223

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

make app package on OS X #223

wants to merge 2 commits into from

Conversation

scheffle
Copy link

This patch makes an application package for juci on Mac OS X.

@eidheim
Copy link
Member

eidheim commented May 15, 2016

Thank you for adding this. I got the following issue however: PATH was not correctly set when starting the application from the OS X search (top right corner of screen). The result was that binaries from /usr/local/bin was not accessible. Although this works if one runs the following in a terminal: open -a juCi++.

One additional issue is that one cannot run juci from terminal anymore, one would have to run open -a juCi++ instead.

@scheffle
Copy link
Author

OK, I don't have a solution for the PATH environment variable not including "/usr/local/bin". But I think that this stuff should be solved in the app itself. (You can already set the preference value 'cmake_command' to /usr/local/bin/cmake).

And to run it from terminal, you have to use juCi++.app/Contents/MacOS/juCi++ as launch path.

@eidheim
Copy link
Member

eidheim commented May 15, 2016

I guess we could add /usr/local/bin to PATH when starting juci on OS X.

Maybe add a symbolic link, when doing make install, from /usr/local/bin/juci to /usr/local/bin/juCi++.app/Contents/MacOS/juCi++ so it's similar to other platforms as well?

@scheffle
Copy link
Author

I didn't thought about installation yet. To install an application package to /usr/local/bin is not OSX like.
It depends on how this app should be distributed to end users.

@eidheim
Copy link
Member

eidheim commented May 15, 2016

At least to me, and many developers on OS X, homebrew is essential. I'm thinking that juCi++ could be installable with brew install jucipp someday. However, your changes makes juCi++ runnable through OS X non-terminal functions, which is nice.

Instead of creating download-and-click installables to every platform, we are hoping that package maintainers will continue to create juCi++ packages for the various platforms (through their package systems), like what is done for arch and msys2 through git-packages (and hopefully soon release packages). Until then, I guess manual git/build/make/install is fine.

@scheffle
Copy link
Author

OK, then for now to add a symlink as you suggested would be a first start then. I will try to add this to the cmake file and update this pull request then.

@eidheim
Copy link
Member

eidheim commented May 23, 2016

Sorry for being late on this. Still considering what to do here. An OS X package is nice, but it brings extra complexity which may lead to issues in the future. And then there is the PATH problem when starting juci outside of a terminal. We have to keep things simple in order to support so many platforms (12 platforms last time I checked!).

@scheffle
Copy link
Author

It's up to you. If you think that the maintainability cost are too high, then close this pull request.
For me the PATH problem is no real issue as I think a good c++ IDE should make it easy to set custom paths for its tools.

@eidheim
Copy link
Member

eidheim commented May 27, 2016

I think CPACK is the way to go on OS X as well: https://cmake.org/Wiki/CMake:CPackPackageGenerators#Bundle_.28OSX_only.29.

Then the need of the symbolic link goes away, since a normal make install will work as it does now. But if you do make package an OS X bundle will be created.

@eidheim
Copy link
Member

eidheim commented May 27, 2016

See https://cmake.org/Wiki/CMake/CPackExample for an simple example (although DEB).

@eidheim
Copy link
Member

eidheim commented Jul 10, 2016

I've added CPack now, and once I figure out how to setup the OS X bundle using CPack I'll merge this most likely (the Info.plist is still needed if I'm not mistaken).

edit: We also have to fix the PATH issue.

@scheffle
Copy link
Author

OK, sorry I have no time to help here.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants