Skip to content
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.

Sign up for GitHub

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

Jump to bottom

'Fix' the Sierra build error by adding -tags legacy #2594

Merged
merged 1 commit into from
Oct 31, 2021
Merged

'Fix' the Sierra build error by adding -tags legacy #2594

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
2 changes: 1 addition & 1 deletion app/app_darwin.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ package app

/*
#cgo CFLAGS: -x objective-c
#cgo LDFLAGS: -framework Foundation -framework UserNotifications
#cgo LDFLAGS: -framework Foundation

#include <stdbool.h>
#include <stdlib.h>
Expand Down
17 changes: 13 additions & 4 deletions app/app_darwin.m
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,11 +1,19 @@
// +build !ci

#import <Foundation/Foundation.h>
#if __MAC_OS_X_VERSION_MAX_ALLOWED >= 101400
#import <UserNotifications/UserNotifications.h>
#endif

static int notifyNum = 0;

extern void fallbackSend(char *cTitle, char *cBody);

bool isBundled() {
return [[NSBundle mainBundle] bundleIdentifier] != nil;
}

#if __MAC_OS_X_VERSION_MAX_ALLOWED >= 101400
void doSendNotification(UNUserNotificationCenter *center, NSString *title, NSString *body) {
UNMutableNotificationContent *content = [UNMutableNotificationContent new];
[content autorelease];
Expand All @@ -24,10 +32,6 @@ void doSendNotification(UNUserNotificationCenter *center, NSString *title, NSStr
}];
}

bool isBundled() {
return [[NSBundle mainBundle] bundleIdentifier] != nil;
}

void sendNotification(char *cTitle, char *cBody) {
UNUserNotificationCenter *center = [UNUserNotificationCenter currentNotificationCenter];
NSString *title = [NSString stringWithUTF8String:cTitle];
Expand All @@ -49,3 +53,8 @@ void sendNotification(char *cTitle, char *cBody) {
}
}];
}
#else
void sendNotification(char *cTitle, char *cBody) {
fallbackSend(cTitle, cBody);
}
#endif
9 changes: 9 additions & 0 deletions app/app_notlegacy_darwin.go
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
// +build !ci
// +build !legacy
Comment on lines +1 to +2
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// +build !ci
// +build !legacy
//go:build !ci && !legacy
// +build !ci,!legacy

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, this is built on the release branch - that has not migrated to Go 1.17 build flag convention yet, that is only on develop

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know how the tag can be more general than legacy. I commented above how I think this can apply.
After release I will add it to https://developer.fyne.io/started/compiling

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the code dedicated in the current release branch and will never be contained in future releases? If we have everything in the develop compatible with go:build whereas this newly introduced one is not, then when the develop branch is merged into the release branch, we will have missed cases such as this one.

Having an additional go:build should be no problem at all since they are useless for those older compilers. If 1.18 is released, then users who use the newest compiler will not be able to use the current release as a module because their compiler cannot recognize the build tags. So in any case, we will have to adapt the go:build tag for every supported release.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the code dedicated in the current release branch and will never be contained in future releases?

When the release branch does merge to develop this will be addressed - the linters will not allow it in without that code added :). However adding it to this PR and the branch would be in an inconsistent state.
I don't think we will still be working on v2.0.x bug fix releases when Go 1.18 is released. If we are then this branch can be updated.


package app

/*
#cgo LDFLAGS: -framework Foundation -framework UserNotifications
*/
import "C"
4 changes: 2 additions & 2 deletions internal/driver/glfw/menu_darwin.m
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,8 +9,8 @@
NSControlStateValue STATE_ON = NSControlStateValueOn;
NSControlStateValue STATE_OFF = NSControlStateValueOff;
#else
NSControlStateValue STATE_ON = NSOnState;
NSControlStateValue STATE_OFF = NSOffState;
NSCellStateValue STATE_ON = NSOnState;
NSCellStateValue STATE_OFF = NSOffState;
#endif


Expand Down