-
Notifications
You must be signed in to change notification settings - Fork 254
Add build tags to signal package #1119
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
Conversation
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.
Great effort! It's much better than C macros. I am a little bit confused by build tags which seems inconsistent/missing in some places.
./_assets/patches/patcher -b . -p geth-xgo -r | ||
@echo "iOS framework cross compilation done." | ||
|
||
statusgo-library: ##@cross-compile Build status-go as static library for current platform | ||
@echo "Building static library..." | ||
go build -buildmode=c-archive -o $(GOBIN)/libstatus.a ./lib | ||
go build -buildmode=c-archive -tags library -o $(GOBIN)/libstatus.a ./lib |
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.
Shouldn't this line also read as -tags library $(BUILD_TAGS)
? It might have been missed before.
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.
@adambabik so I anticipated removal of BUILD_TAGS in this PR. Does it make sense to remove it after #1121? Or we still want/need to define BUILD_TAGS from the environment?
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 don't know of any use case for BUILD_TAGS
now so we can remove all references.
signal/signals.go
Outdated
str := C.CString(string(data)) | ||
C.StatusServiceSignalEvent(str) | ||
C.free(unsafe.Pointer(str)) | ||
notificationHandlerMutex.Lock() |
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.
RLock()
if we have sync.RWMutex
. Regular mutex should also be fine.
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.
Right, good spot!
@@ -0,0 +1,153 @@ | |||
// ====================================================================================== |
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.
Does it miss // +build library,android
?
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.
Uhm, I don't think so, but it might be worth adding. The main issue here is that both build tags and file naming conventions are kinda redundant, and I don't want to bring confusion by using both. So, here I used _android.c
name and it seems to work properly because CGo now is enabled (and this means that C files are even considered by compiler to look into) only on library
builds (and that, in its turn enforced by build tags in .go files).
So it's a bit complicated, but I'm going to refactor signals anyway, so at least this combination works for now. (I need to address tests fails on CI though, maybe they're related)
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.
So does it mean that naming a file signals_android.c
will compile it only for android
environment?
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.
@adambabik yes! I didn't find any mention of it in docs, but empirically that's the way how it seemed to work (I spent almost a day, trying out those things and waiting for xgo builds)
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.
Thanks, now it makes more sense!
@@ -0,0 +1,49 @@ | |||
// ====================================================================================== |
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.
Similarly here // +build library,darwin,arm
?
int result = JNI_VERSION_1_6; | ||
|
||
gJavaVM = vm; | ||
// +build library,!android,!arm |
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.
!darwin
missing?
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.
No, darwin
is a valid architecture name for MacOS X.
@@ -0,0 +1,101 @@ | |||
// +build library,!darwin |
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.
!android
?
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.
So signals_library.go
is for both Desktop and Android builds (their C files are identical). I was thinking to make it more explicit and just copy code, but then decided to do this way. Anyway, going to refactor it asap.
It's interesting how only three dimensions of build options can create so much confusion :)
…n thousands of line of CI test output
Codeclimate doesn't understand Go build tags. |
The CI was falling due to current signals design. Seems like signals handler was set from two different places during the test, and so test was filing. After introducing debug output, it worked fine, because of tiny delay. Which, again, shows that signals package begs for refactoring. |
This PR introduces build tags (or build constraints) to the
signal
package. The code is this package differs for different platforms and build modes, namely:It remove CGo dependency on signal package for
statusd
and tests. (Also, part of the memleak mitigation (#1067 (comment)).
Also, it would be nice to have non-Cgo variant a default (easier with
go get
, tests, vendoring, etc.)library
. No need to use it manually, it's added to Makefile for commandsstatusgo-library
,statusgo-ios
andstatusgo-android
.signals_android.c
andsignals_darwin_arm.c
respectivelysignals_library.go
(andsignals_darwin.go
because of two iOS specific CGo imports that need to be in that Go file for CGo magic to work)signals.go
More info on build tags: https://golang.org/pkg/go/build/#hdr-Build_Constraints and https://dave.cheney.net/2013/10/12/how-to-use-conditional-compilation-with-the-go-build-tool
As there is a build code changes involved and file layout changed, I would be pleasantly surprised if CI, tests and cross build with status-react and status-desktop will Go smoothly :)
Closes #1115