Skip to content

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

Merged
merged 8 commits into from
Aug 7, 2018
Merged

Add build tags to signal package #1119

merged 8 commits into from
Aug 7, 2018

Conversation

divan
Copy link
Contributor

@divan divan commented Jul 26, 2018

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:

  • iOS build as a library (require CGo)
  • Android build as a library (require CGo)
  • Desktop build as a library (require CGo)
  • normal build of statusd or running local tests (not requiring CGo)

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.)

  • a new build tag introduced - library. No need to use it manually, it's added to Makefile for commands statusgo-library, statusgo-ios and statusgo-android.
  • Android and iOS specific C code moved to signals_android.c and signals_darwin_arm.c respectively
  • Library/CGo-specific code moved to signals_library.go (and signals_darwin.go because of two iOS specific CGo imports that need to be in that Go file for CGo magic to work)
  • non-library (default) signals implementation that doesn't link with CGo is moved to 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

Copy link
Contributor

@adambabik adambabik left a 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
Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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.

str := C.CString(string(data))
C.StatusServiceSignalEvent(str)
C.free(unsafe.Pointer(str))
notificationHandlerMutex.Lock()
Copy link
Contributor

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.

Copy link
Contributor Author

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 @@
// ======================================================================================
Copy link
Contributor

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?

Copy link
Contributor Author

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)

Copy link
Contributor

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?

Copy link
Contributor Author

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)

Copy link
Contributor

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 @@
// ======================================================================================
Copy link
Contributor

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
Copy link
Contributor

Choose a reason for hiding this comment

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

!darwin missing?

Copy link
Contributor Author

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
Copy link
Contributor

Choose a reason for hiding this comment

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

!android?

Copy link
Contributor Author

@divan divan Jul 29, 2018

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 :)

@divan
Copy link
Contributor Author

divan commented Jul 29, 2018

Codeclimate doesn't understand Go build tags.

@divan
Copy link
Contributor Author

divan commented Jul 29, 2018

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.

@divan divan merged commit 27e432a into develop Aug 7, 2018
adambabik added a commit that referenced this pull request Aug 9, 2018
adambabik added a commit that referenced this pull request Aug 10, 2018
@pedropombeiro pedropombeiro deleted the signal_tags branch August 15, 2018 13:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants