-
Notifications
You must be signed in to change notification settings - Fork 20
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
Translocation fix #273
Translocation fix #273
Conversation
... and don't insert a period in place of it in the descriptive version strings
This allows for testing of the setup application without needed packaging
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, just a question about the installation destination stuff when packaging & a couple of small tweaks
|
||
# Common Files (all OS) | ||
# note: '.' is "Setup EAR Production Suite.app/Contents/Resources" on MacOS |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is only true when run on CI? (took me a while to track it down, but I think '.' means the root of CMAKE_INSTALL_PREFIX, which is set by build.yml)
If we were to configure and install locally with EPS_PACKAGE set, does that mean we'd get everything in the CMAKE_INSTALL_PREFIX root, (and presumably the setup app would be broken?)
Is there a reason for doing it that way, or would we be better with
install(FILES
README.pdf
LICENSE.pdf
DESTINATION
# note still starts with a '.' otherwise cmake will assume
# generator expression resolves to an absolute path
# also might need to escape the spaces
# also might be broken, I'm just thinking out loud :)
.$<$<PLATFORM_ID:DARWIN>:/Setup EAR Production Suite.app/Contents/Resources>
# other install commands
and keeping the install prefix consistent?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh wait, I just saw your comment at the top of the PR. Sorry :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess it's maybe still valid as it's nice to be able to do a CI-style build locally (I don't think doing it this way negates that as the packaging file is only run if specified via a cache var). If it's hard for some reason (the post-build step suggests it probably is) then maybe keep things as they are.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Issue #275 opened to tackle local packaging at a later date
Some mac machines seem to use translocation on the setup application bundle even though the application and the disk image itself is signed. This is not expected behaviour going by Apple Developer documentation - a signed and notorised disk image containing signed binaries should not need any translocation. When translocation happens, the setup application can not locate the setup files as the application has been moved to a random directory. Perhaps a bug? Only seems to affect the odd machine.
In any case, we need a workaround. This fix places all of the setup files in the Resources folder of the setup application. This way, even if translocation occurs, setup still has access to all of the setup files it needs.
Setup EAR Production Suite.app/Contents/Resources
Other bits to support it;
PARENT_SCOPE
set
s to push it up through the chain.) Less chance of forgetting any new plugin during copy stage this way.