2020-07-02 18:40:49 +00:00
|
|
|
# Copyright (c) 2020 Status Research & Development GmbH. Licensed under
|
2020-07-02 13:20:16 +00:00
|
|
|
# either of:
|
|
|
|
|
# - Apache License, version 2.0
|
|
|
|
|
# - MIT license
|
|
|
|
|
# at your option. This file may not be copied, modified, or distributed except
|
|
|
|
|
# according to those terms.
|
|
|
|
|
|
|
|
|
|
SHELL := bash # the shell used internally by Make
|
|
|
|
|
|
|
|
|
|
# used inside the included makefiles
|
|
|
|
|
BUILD_SYSTEM_DIR := vendor/nimbus-build-system
|
|
|
|
|
|
|
|
|
|
# we don't want an error here, so we can handle things later, in the ".DEFAULT" target
|
|
|
|
|
-include $(BUILD_SYSTEM_DIR)/makefiles/variables.mk
|
|
|
|
|
|
|
|
|
|
.PHONY: \
|
|
|
|
|
all \
|
|
|
|
|
bottles \
|
|
|
|
|
bottles-dummy \
|
|
|
|
|
bottles-macos \
|
|
|
|
|
clean \
|
feat: introduce Nim impl of hashMessage in reorganized library
Introduce a Nim implementation of `hashMessage` situated in a reorganized
library with *Nim-oriented* and *C-oriented* entry points inspired by the
[shim strategy][shim-strat] suggested by @arnetheduck.
The goal of this approach (per @iurimatias, at least as I understood what was
discussed and tasked) is for Nim implementations of equivalent functionality to
eventually supersede existing [status-go][sgo] implementations.
These changes will benefit from feedback by @arnetheduck, @zah,
@stefantalpalaru, @siphiuel, other members of stimbus/desktop, et al. – my dev
experiences with Nim and C are quite limited to date. Some of the changes may
be problematic, unnecessary, suboptimal, etc. I may have reified the *"shim
strategy"* badly. Please shred this PR apart and lead me to the 💡
light. Thanks for your help!
N.B. `tests/nim/login.nim` and `tests/c/login.c` use loops that never
terminate (introduced prior to this PR). Future work will attempt to remedy
that shortcoming but it's out of scope for this PR.
The reorganized library can be grouped into two trees of `.nim` sources, but
note that `import` statements interlink some of them.
**Nim-oriented**
```
├── src
│ ├── nim_status
│ │ ├── go
│ │ │ └── shim.nim
│ │ ├── lib
│ │ │ ├── shim.nim
│ │ │ └── util.nim
│ │ ├── lib.nim
│ │ └── types.nim
│ └── nim_status.nim
```
**C-oriented**
```
├── src
│ ├── nim_status
│ │ ├── c
│ │ │ ├── go
│ │ │ │ └── shim.nim
│ │ │ ├── lib
│ │ │ │ └── shim.nim
│ │ │ ├── lib.nim
│ │ │ ├── nim_status.nim
│ │ │ └── sys.nim
```
The key difference between the Nim sources in one tree and the other is that
the Nim-oriented sources are intended to be consumed by other Nim
sources (e.g. [status-im/nim-status-client][nsc] via Nim's built-in `import`),
while the C-oriented sources are intended to be compiled to a C
library (e.g. `nim_status.a`) and then linked/called by other C code. To that
end, the former use e.g. `string` in call signatures while the latter use
`cstring`. Along the same lines, the C-oriented `proc`s may return pointers to
memory allocated with `c_malloc` such that it's up to the caller to free the
memory occupied by the return values.
Both `src/nim_status/go/shim.nim` and `src/nim_status/c/go/shim.nim` are pure
shims around status-go, the main difference being their call signatures.
With `src/nim_status/lib.nim` the intention is to implement functionality in a
manner independent of status-go's idioms.
In `src/nim_status/[c/]lib/shim.nim` the intention is to wrap around
`src/nim_status/lib.nim` in a way that preserves status-go's call signatures
and formatting. For example, the `hashMessage` proc introduced in this PR in
`src/nim_status/lib.nim` returns a hex string like `0xabcd...` while
`lib/shim.nim` returns JSON that's a match for status-go:
`{"result":"0xabcd..."}`.
Both `src/nim_status.nim` and `src/nim_status/c/nim_status.nim` represent a
hybrid of `go/shim.nim` and `lib/shim.nim`. Again, the goal is that over time
more and more `proc`s implemented in Nim replace the shims around status-go.
Callers that don't need to consume return values formatted according to
status-go conventions can use `lib.nim` directly, e.g. via `import
nim_status/lib` or by compiling `src/nim_status/c/lib.nim` and linking/calling
from C.
`c_malloc` has been copied (in `src/nim_status/c/sys.nim`) from the source of
Nim's `system/ansi_c` because `ansi_c` is an undocumented internal API.
A Nim template or pragma might be useful with respect to usgae of `c_malloc` in
`src/nim_status/c/*`, i.e. to cut down on repetition.
Use of `{.exportc.}` is limited to the `src/nim_status/c/nim_status.nim` hybrid
shim to avoid imposing exported symbols on C-oriented library consumers who may
wish to compose things in a different manner.
With respect to the Nim implementation of `hashMessage`, both Nim-oriented and
C-oriented tests have been implemented. Whether doubling up the tests is really
necessary/desirable for all `proc`s is probably worth discussing.
Adjust `.gitignore` and refactor `Makefile` accordingly; apply some lessons
learned while working on [status-im/nim-status-client][nsc].
Closes #34.
[shim-strat]: https://github.com/status-im/nim-status/issues/5#issuecomment-647497745
[sgo]: https://github.com/status-im/status-go
[nsc]: https://github.com/status-im/nim-status-client
2020-07-23 22:15:09 +00:00
|
|
|
clean-build-dirs \
|
|
|
|
|
clean-data-dirs \
|
|
|
|
|
create-data-dirs \
|
2020-07-02 13:20:16 +00:00
|
|
|
deps \
|
|
|
|
|
nim_status \
|
feat: introduce Nim impl of hashMessage in reorganized library
Introduce a Nim implementation of `hashMessage` situated in a reorganized
library with *Nim-oriented* and *C-oriented* entry points inspired by the
[shim strategy][shim-strat] suggested by @arnetheduck.
The goal of this approach (per @iurimatias, at least as I understood what was
discussed and tasked) is for Nim implementations of equivalent functionality to
eventually supersede existing [status-go][sgo] implementations.
These changes will benefit from feedback by @arnetheduck, @zah,
@stefantalpalaru, @siphiuel, other members of stimbus/desktop, et al. – my dev
experiences with Nim and C are quite limited to date. Some of the changes may
be problematic, unnecessary, suboptimal, etc. I may have reified the *"shim
strategy"* badly. Please shred this PR apart and lead me to the 💡
light. Thanks for your help!
N.B. `tests/nim/login.nim` and `tests/c/login.c` use loops that never
terminate (introduced prior to this PR). Future work will attempt to remedy
that shortcoming but it's out of scope for this PR.
The reorganized library can be grouped into two trees of `.nim` sources, but
note that `import` statements interlink some of them.
**Nim-oriented**
```
├── src
│ ├── nim_status
│ │ ├── go
│ │ │ └── shim.nim
│ │ ├── lib
│ │ │ ├── shim.nim
│ │ │ └── util.nim
│ │ ├── lib.nim
│ │ └── types.nim
│ └── nim_status.nim
```
**C-oriented**
```
├── src
│ ├── nim_status
│ │ ├── c
│ │ │ ├── go
│ │ │ │ └── shim.nim
│ │ │ ├── lib
│ │ │ │ └── shim.nim
│ │ │ ├── lib.nim
│ │ │ ├── nim_status.nim
│ │ │ └── sys.nim
```
The key difference between the Nim sources in one tree and the other is that
the Nim-oriented sources are intended to be consumed by other Nim
sources (e.g. [status-im/nim-status-client][nsc] via Nim's built-in `import`),
while the C-oriented sources are intended to be compiled to a C
library (e.g. `nim_status.a`) and then linked/called by other C code. To that
end, the former use e.g. `string` in call signatures while the latter use
`cstring`. Along the same lines, the C-oriented `proc`s may return pointers to
memory allocated with `c_malloc` such that it's up to the caller to free the
memory occupied by the return values.
Both `src/nim_status/go/shim.nim` and `src/nim_status/c/go/shim.nim` are pure
shims around status-go, the main difference being their call signatures.
With `src/nim_status/lib.nim` the intention is to implement functionality in a
manner independent of status-go's idioms.
In `src/nim_status/[c/]lib/shim.nim` the intention is to wrap around
`src/nim_status/lib.nim` in a way that preserves status-go's call signatures
and formatting. For example, the `hashMessage` proc introduced in this PR in
`src/nim_status/lib.nim` returns a hex string like `0xabcd...` while
`lib/shim.nim` returns JSON that's a match for status-go:
`{"result":"0xabcd..."}`.
Both `src/nim_status.nim` and `src/nim_status/c/nim_status.nim` represent a
hybrid of `go/shim.nim` and `lib/shim.nim`. Again, the goal is that over time
more and more `proc`s implemented in Nim replace the shims around status-go.
Callers that don't need to consume return values formatted according to
status-go conventions can use `lib.nim` directly, e.g. via `import
nim_status/lib` or by compiling `src/nim_status/c/lib.nim` and linking/calling
from C.
`c_malloc` has been copied (in `src/nim_status/c/sys.nim`) from the source of
Nim's `system/ansi_c` because `ansi_c` is an undocumented internal API.
A Nim template or pragma might be useful with respect to usgae of `c_malloc` in
`src/nim_status/c/*`, i.e. to cut down on repetition.
Use of `{.exportc.}` is limited to the `src/nim_status/c/nim_status.nim` hybrid
shim to avoid imposing exported symbols on C-oriented library consumers who may
wish to compose things in a different manner.
With respect to the Nim implementation of `hashMessage`, both Nim-oriented and
C-oriented tests have been implemented. Whether doubling up the tests is really
necessary/desirable for all `proc`s is probably worth discussing.
Adjust `.gitignore` and refactor `Makefile` accordingly; apply some lessons
learned while working on [status-im/nim-status-client][nsc].
Closes #34.
[shim-strat]: https://github.com/status-im/nim-status/issues/5#issuecomment-647497745
[sgo]: https://github.com/status-im/status-go
[nsc]: https://github.com/status-im/nim-status-client
2020-07-23 22:15:09 +00:00
|
|
|
status-go \
|
|
|
|
|
test \
|
2020-08-10 16:48:30 +00:00
|
|
|
test-c-shims \
|
|
|
|
|
test-c-login \
|
feat: introduce Nim impl of hashMessage in reorganized library
Introduce a Nim implementation of `hashMessage` situated in a reorganized
library with *Nim-oriented* and *C-oriented* entry points inspired by the
[shim strategy][shim-strat] suggested by @arnetheduck.
The goal of this approach (per @iurimatias, at least as I understood what was
discussed and tasked) is for Nim implementations of equivalent functionality to
eventually supersede existing [status-go][sgo] implementations.
These changes will benefit from feedback by @arnetheduck, @zah,
@stefantalpalaru, @siphiuel, other members of stimbus/desktop, et al. – my dev
experiences with Nim and C are quite limited to date. Some of the changes may
be problematic, unnecessary, suboptimal, etc. I may have reified the *"shim
strategy"* badly. Please shred this PR apart and lead me to the 💡
light. Thanks for your help!
N.B. `tests/nim/login.nim` and `tests/c/login.c` use loops that never
terminate (introduced prior to this PR). Future work will attempt to remedy
that shortcoming but it's out of scope for this PR.
The reorganized library can be grouped into two trees of `.nim` sources, but
note that `import` statements interlink some of them.
**Nim-oriented**
```
├── src
│ ├── nim_status
│ │ ├── go
│ │ │ └── shim.nim
│ │ ├── lib
│ │ │ ├── shim.nim
│ │ │ └── util.nim
│ │ ├── lib.nim
│ │ └── types.nim
│ └── nim_status.nim
```
**C-oriented**
```
├── src
│ ├── nim_status
│ │ ├── c
│ │ │ ├── go
│ │ │ │ └── shim.nim
│ │ │ ├── lib
│ │ │ │ └── shim.nim
│ │ │ ├── lib.nim
│ │ │ ├── nim_status.nim
│ │ │ └── sys.nim
```
The key difference between the Nim sources in one tree and the other is that
the Nim-oriented sources are intended to be consumed by other Nim
sources (e.g. [status-im/nim-status-client][nsc] via Nim's built-in `import`),
while the C-oriented sources are intended to be compiled to a C
library (e.g. `nim_status.a`) and then linked/called by other C code. To that
end, the former use e.g. `string` in call signatures while the latter use
`cstring`. Along the same lines, the C-oriented `proc`s may return pointers to
memory allocated with `c_malloc` such that it's up to the caller to free the
memory occupied by the return values.
Both `src/nim_status/go/shim.nim` and `src/nim_status/c/go/shim.nim` are pure
shims around status-go, the main difference being their call signatures.
With `src/nim_status/lib.nim` the intention is to implement functionality in a
manner independent of status-go's idioms.
In `src/nim_status/[c/]lib/shim.nim` the intention is to wrap around
`src/nim_status/lib.nim` in a way that preserves status-go's call signatures
and formatting. For example, the `hashMessage` proc introduced in this PR in
`src/nim_status/lib.nim` returns a hex string like `0xabcd...` while
`lib/shim.nim` returns JSON that's a match for status-go:
`{"result":"0xabcd..."}`.
Both `src/nim_status.nim` and `src/nim_status/c/nim_status.nim` represent a
hybrid of `go/shim.nim` and `lib/shim.nim`. Again, the goal is that over time
more and more `proc`s implemented in Nim replace the shims around status-go.
Callers that don't need to consume return values formatted according to
status-go conventions can use `lib.nim` directly, e.g. via `import
nim_status/lib` or by compiling `src/nim_status/c/lib.nim` and linking/calling
from C.
`c_malloc` has been copied (in `src/nim_status/c/sys.nim`) from the source of
Nim's `system/ansi_c` because `ansi_c` is an undocumented internal API.
A Nim template or pragma might be useful with respect to usgae of `c_malloc` in
`src/nim_status/c/*`, i.e. to cut down on repetition.
Use of `{.exportc.}` is limited to the `src/nim_status/c/nim_status.nim` hybrid
shim to avoid imposing exported symbols on C-oriented library consumers who may
wish to compose things in a different manner.
With respect to the Nim implementation of `hashMessage`, both Nim-oriented and
C-oriented tests have been implemented. Whether doubling up the tests is really
necessary/desirable for all `proc`s is probably worth discussing.
Adjust `.gitignore` and refactor `Makefile` accordingly; apply some lessons
learned while working on [status-im/nim-status-client][nsc].
Closes #34.
[shim-strat]: https://github.com/status-im/nim-status/issues/5#issuecomment-647497745
[sgo]: https://github.com/status-im/status-go
[nsc]: https://github.com/status-im/nim-status-client
2020-07-23 22:15:09 +00:00
|
|
|
tests \
|
|
|
|
|
tests-c \
|
|
|
|
|
tests-nim \
|
|
|
|
|
update
|
2020-07-02 13:20:16 +00:00
|
|
|
|
|
|
|
|
ifeq ($(NIM_PARAMS),)
|
|
|
|
|
# "variables.mk" was not included, so we update the submodules.
|
|
|
|
|
GIT_SUBMODULE_UPDATE := git submodule update --init --recursive
|
|
|
|
|
.DEFAULT:
|
|
|
|
|
+@ echo -e "Git submodules not found. Running '$(GIT_SUBMODULE_UPDATE)'.\n"; \
|
|
|
|
|
$(GIT_SUBMODULE_UPDATE); \
|
|
|
|
|
echo
|
|
|
|
|
# Now that the included *.mk files appeared, and are newer than this file, Make will restart itself:
|
|
|
|
|
# https://www.gnu.org/software/make/manual/make.html#Remaking-Makefiles
|
|
|
|
|
#
|
|
|
|
|
# After restarting, it will execute its original goal, so we don't have to start a child Make here
|
|
|
|
|
# with "$(MAKE) $(MAKECMDGOALS)". Isn't hidden control flow great?
|
|
|
|
|
|
|
|
|
|
else # "variables.mk" was included. Business as usual until the end of this file.
|
|
|
|
|
|
|
|
|
|
all: nim_status
|
|
|
|
|
|
|
|
|
|
# must be included after the default target
|
|
|
|
|
-include $(BUILD_SYSTEM_DIR)/makefiles/targets.mk
|
|
|
|
|
|
|
|
|
|
ifeq ($(OS),Windows_NT) # is Windows_NT on XP, 2000, 7, Vista, 10...
|
|
|
|
|
detected_OS := Windows
|
|
|
|
|
else
|
|
|
|
|
detected_OS := $(strip $(shell uname))
|
|
|
|
|
endif
|
|
|
|
|
|
feat: introduce Nim impl of hashMessage in reorganized library
Introduce a Nim implementation of `hashMessage` situated in a reorganized
library with *Nim-oriented* and *C-oriented* entry points inspired by the
[shim strategy][shim-strat] suggested by @arnetheduck.
The goal of this approach (per @iurimatias, at least as I understood what was
discussed and tasked) is for Nim implementations of equivalent functionality to
eventually supersede existing [status-go][sgo] implementations.
These changes will benefit from feedback by @arnetheduck, @zah,
@stefantalpalaru, @siphiuel, other members of stimbus/desktop, et al. – my dev
experiences with Nim and C are quite limited to date. Some of the changes may
be problematic, unnecessary, suboptimal, etc. I may have reified the *"shim
strategy"* badly. Please shred this PR apart and lead me to the 💡
light. Thanks for your help!
N.B. `tests/nim/login.nim` and `tests/c/login.c` use loops that never
terminate (introduced prior to this PR). Future work will attempt to remedy
that shortcoming but it's out of scope for this PR.
The reorganized library can be grouped into two trees of `.nim` sources, but
note that `import` statements interlink some of them.
**Nim-oriented**
```
├── src
│ ├── nim_status
│ │ ├── go
│ │ │ └── shim.nim
│ │ ├── lib
│ │ │ ├── shim.nim
│ │ │ └── util.nim
│ │ ├── lib.nim
│ │ └── types.nim
│ └── nim_status.nim
```
**C-oriented**
```
├── src
│ ├── nim_status
│ │ ├── c
│ │ │ ├── go
│ │ │ │ └── shim.nim
│ │ │ ├── lib
│ │ │ │ └── shim.nim
│ │ │ ├── lib.nim
│ │ │ ├── nim_status.nim
│ │ │ └── sys.nim
```
The key difference between the Nim sources in one tree and the other is that
the Nim-oriented sources are intended to be consumed by other Nim
sources (e.g. [status-im/nim-status-client][nsc] via Nim's built-in `import`),
while the C-oriented sources are intended to be compiled to a C
library (e.g. `nim_status.a`) and then linked/called by other C code. To that
end, the former use e.g. `string` in call signatures while the latter use
`cstring`. Along the same lines, the C-oriented `proc`s may return pointers to
memory allocated with `c_malloc` such that it's up to the caller to free the
memory occupied by the return values.
Both `src/nim_status/go/shim.nim` and `src/nim_status/c/go/shim.nim` are pure
shims around status-go, the main difference being their call signatures.
With `src/nim_status/lib.nim` the intention is to implement functionality in a
manner independent of status-go's idioms.
In `src/nim_status/[c/]lib/shim.nim` the intention is to wrap around
`src/nim_status/lib.nim` in a way that preserves status-go's call signatures
and formatting. For example, the `hashMessage` proc introduced in this PR in
`src/nim_status/lib.nim` returns a hex string like `0xabcd...` while
`lib/shim.nim` returns JSON that's a match for status-go:
`{"result":"0xabcd..."}`.
Both `src/nim_status.nim` and `src/nim_status/c/nim_status.nim` represent a
hybrid of `go/shim.nim` and `lib/shim.nim`. Again, the goal is that over time
more and more `proc`s implemented in Nim replace the shims around status-go.
Callers that don't need to consume return values formatted according to
status-go conventions can use `lib.nim` directly, e.g. via `import
nim_status/lib` or by compiling `src/nim_status/c/lib.nim` and linking/calling
from C.
`c_malloc` has been copied (in `src/nim_status/c/sys.nim`) from the source of
Nim's `system/ansi_c` because `ansi_c` is an undocumented internal API.
A Nim template or pragma might be useful with respect to usgae of `c_malloc` in
`src/nim_status/c/*`, i.e. to cut down on repetition.
Use of `{.exportc.}` is limited to the `src/nim_status/c/nim_status.nim` hybrid
shim to avoid imposing exported symbols on C-oriented library consumers who may
wish to compose things in a different manner.
With respect to the Nim implementation of `hashMessage`, both Nim-oriented and
C-oriented tests have been implemented. Whether doubling up the tests is really
necessary/desirable for all `proc`s is probably worth discussing.
Adjust `.gitignore` and refactor `Makefile` accordingly; apply some lessons
learned while working on [status-im/nim-status-client][nsc].
Closes #34.
[shim-strat]: https://github.com/status-im/nim-status/issues/5#issuecomment-647497745
[sgo]: https://github.com/status-im/status-go
[nsc]: https://github.com/status-im/nim-status-client
2020-07-23 22:15:09 +00:00
|
|
|
ifeq ($(detected_OS),Darwin)
|
2020-07-02 13:20:16 +00:00
|
|
|
BOTTLES_TARGET := bottles-macos
|
|
|
|
|
MACOSX_DEPLOYMENT_TARGET := 10.13
|
|
|
|
|
export MACOSX_DEPLOYMENT_TARGET
|
|
|
|
|
CGO_CFLAGS := -mmacosx-version-min=10.13
|
|
|
|
|
export CGO_CFLAGS
|
|
|
|
|
CFLAGS := -mmacosx-version-min=10.13
|
|
|
|
|
export CFLAGS
|
2020-08-10 16:48:30 +00:00
|
|
|
LIBSTATUS_EXT := dylib
|
|
|
|
|
else ifeq ($(detected_OS),Windows)
|
|
|
|
|
LIBSTATUS_EXT := dll
|
2020-07-02 13:20:16 +00:00
|
|
|
else
|
|
|
|
|
BOTTLES_TARGET := bottles-dummy
|
2020-08-10 16:48:30 +00:00
|
|
|
LIBSTATUS_EXT := so
|
2020-07-02 13:20:16 +00:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
bottles: $(BOTTLES_TARGET)
|
|
|
|
|
|
|
|
|
|
bottles-dummy: ;
|
|
|
|
|
|
|
|
|
|
BOTTLE_OPENSSL := bottles/openssl/INSTALL_RECEIPT.json
|
|
|
|
|
|
|
|
|
|
$(BOTTLE_OPENSSL):
|
|
|
|
|
rm -rf bottles/Downloads/openssl* bottles/openssl*
|
|
|
|
|
mkdir -p bottles/Downloads
|
|
|
|
|
cd bottles/Downloads && \
|
|
|
|
|
wget -O openssl.tar.gz "https://bintray.com/homebrew/bottles/download_file?file_path=openssl%401.1-1.1.1g.high_sierra.bottle.tar.gz" && \
|
|
|
|
|
tar xzf openssl* && \
|
|
|
|
|
mv openssl@1.1/1.1.1g ../openssl
|
|
|
|
|
|
|
|
|
|
BOTTLE_PCRE := bottles/pcre/INSTALL_RECEIPT.json
|
|
|
|
|
|
|
|
|
|
$(BOTTLE_PCRE):
|
|
|
|
|
rm -rf bottles/Downloads/pcre* bottles/pcre*
|
|
|
|
|
mkdir -p bottles/Downloads
|
|
|
|
|
cd bottles/Downloads && \
|
|
|
|
|
wget -O pcre.tar.gz "https://bintray.com/homebrew/bottles/download_file?file_path=pcre-8.44.high_sierra.bottle.tar.gz" && \
|
|
|
|
|
tar xzf pcre* && \
|
|
|
|
|
mv pcre/8.44 ../pcre
|
|
|
|
|
|
|
|
|
|
bottles-macos: | $(BOTTLE_OPENSSL) $(BOTTLE_PCRE)
|
|
|
|
|
rm -rf bottles/Downloads
|
|
|
|
|
|
2020-08-10 16:48:30 +00:00
|
|
|
ifeq ($(detected_OS),Darwin)
|
|
|
|
|
NIM_DEP_LIBS := bottles/openssl/lib/libcrypto.a \
|
|
|
|
|
bottles/openssl/lib/libssl.a \
|
|
|
|
|
bottles/pcre/lib/libpcre.a
|
|
|
|
|
else ifeq ($(detected_OS),Linux)
|
|
|
|
|
NIM_DEP_LIBS := -lcrypto -lssl -lpcre
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
NIM_WINDOWS_PREBUILT_DLLS ?= DLLs/pcre.dll
|
|
|
|
|
NIM_WINDOWS_PREBUILT_DLLDIR := $(shell pwd)/$(shell dirname "$(NIM_WINDOWS_PREBUILT_DLLS)")
|
|
|
|
|
|
|
|
|
|
$(NIM_WINDOWS_PREBUILT_DLLS):
|
|
|
|
|
ifeq ($(detected_OS),Windows)
|
|
|
|
|
echo -e "\e[92mFetching:\e[39m prebuilt DLLs from nim-lang.org"
|
|
|
|
|
rm -rf DLLs
|
|
|
|
|
mkdir -p DLLs
|
|
|
|
|
cd DLLs && \
|
|
|
|
|
wget https://nim-lang.org/download/dlls.zip && \
|
|
|
|
|
unzip dlls.zip
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
deps: | deps-common bottles $(NIM_WINDOWS_PREBUILT_DLLS)
|
2020-07-02 13:20:16 +00:00
|
|
|
|
feat: introduce Nim impl of hashMessage in reorganized library
Introduce a Nim implementation of `hashMessage` situated in a reorganized
library with *Nim-oriented* and *C-oriented* entry points inspired by the
[shim strategy][shim-strat] suggested by @arnetheduck.
The goal of this approach (per @iurimatias, at least as I understood what was
discussed and tasked) is for Nim implementations of equivalent functionality to
eventually supersede existing [status-go][sgo] implementations.
These changes will benefit from feedback by @arnetheduck, @zah,
@stefantalpalaru, @siphiuel, other members of stimbus/desktop, et al. – my dev
experiences with Nim and C are quite limited to date. Some of the changes may
be problematic, unnecessary, suboptimal, etc. I may have reified the *"shim
strategy"* badly. Please shred this PR apart and lead me to the 💡
light. Thanks for your help!
N.B. `tests/nim/login.nim` and `tests/c/login.c` use loops that never
terminate (introduced prior to this PR). Future work will attempt to remedy
that shortcoming but it's out of scope for this PR.
The reorganized library can be grouped into two trees of `.nim` sources, but
note that `import` statements interlink some of them.
**Nim-oriented**
```
├── src
│ ├── nim_status
│ │ ├── go
│ │ │ └── shim.nim
│ │ ├── lib
│ │ │ ├── shim.nim
│ │ │ └── util.nim
│ │ ├── lib.nim
│ │ └── types.nim
│ └── nim_status.nim
```
**C-oriented**
```
├── src
│ ├── nim_status
│ │ ├── c
│ │ │ ├── go
│ │ │ │ └── shim.nim
│ │ │ ├── lib
│ │ │ │ └── shim.nim
│ │ │ ├── lib.nim
│ │ │ ├── nim_status.nim
│ │ │ └── sys.nim
```
The key difference between the Nim sources in one tree and the other is that
the Nim-oriented sources are intended to be consumed by other Nim
sources (e.g. [status-im/nim-status-client][nsc] via Nim's built-in `import`),
while the C-oriented sources are intended to be compiled to a C
library (e.g. `nim_status.a`) and then linked/called by other C code. To that
end, the former use e.g. `string` in call signatures while the latter use
`cstring`. Along the same lines, the C-oriented `proc`s may return pointers to
memory allocated with `c_malloc` such that it's up to the caller to free the
memory occupied by the return values.
Both `src/nim_status/go/shim.nim` and `src/nim_status/c/go/shim.nim` are pure
shims around status-go, the main difference being their call signatures.
With `src/nim_status/lib.nim` the intention is to implement functionality in a
manner independent of status-go's idioms.
In `src/nim_status/[c/]lib/shim.nim` the intention is to wrap around
`src/nim_status/lib.nim` in a way that preserves status-go's call signatures
and formatting. For example, the `hashMessage` proc introduced in this PR in
`src/nim_status/lib.nim` returns a hex string like `0xabcd...` while
`lib/shim.nim` returns JSON that's a match for status-go:
`{"result":"0xabcd..."}`.
Both `src/nim_status.nim` and `src/nim_status/c/nim_status.nim` represent a
hybrid of `go/shim.nim` and `lib/shim.nim`. Again, the goal is that over time
more and more `proc`s implemented in Nim replace the shims around status-go.
Callers that don't need to consume return values formatted according to
status-go conventions can use `lib.nim` directly, e.g. via `import
nim_status/lib` or by compiling `src/nim_status/c/lib.nim` and linking/calling
from C.
`c_malloc` has been copied (in `src/nim_status/c/sys.nim`) from the source of
Nim's `system/ansi_c` because `ansi_c` is an undocumented internal API.
A Nim template or pragma might be useful with respect to usgae of `c_malloc` in
`src/nim_status/c/*`, i.e. to cut down on repetition.
Use of `{.exportc.}` is limited to the `src/nim_status/c/nim_status.nim` hybrid
shim to avoid imposing exported symbols on C-oriented library consumers who may
wish to compose things in a different manner.
With respect to the Nim implementation of `hashMessage`, both Nim-oriented and
C-oriented tests have been implemented. Whether doubling up the tests is really
necessary/desirable for all `proc`s is probably worth discussing.
Adjust `.gitignore` and refactor `Makefile` accordingly; apply some lessons
learned while working on [status-im/nim-status-client][nsc].
Closes #34.
[shim-strat]: https://github.com/status-im/nim-status/issues/5#issuecomment-647497745
[sgo]: https://github.com/status-im/status-go
[nsc]: https://github.com/status-im/nim-status-client
2020-07-23 22:15:09 +00:00
|
|
|
update: | update-common
|
|
|
|
|
|
|
|
|
|
ifeq ($(detected_OS),Darwin)
|
2020-08-10 16:48:30 +00:00
|
|
|
FRAMEWORKS := -framework CoreFoundation -framework CoreServices -framework IOKit -framework Security
|
|
|
|
|
NIM_PARAMS := $(NIM_PARAMS) -L:"$(FRAMEWORKS)"
|
2020-07-02 13:20:16 +00:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
# TODO: control debug/release builds with a Make var
|
|
|
|
|
# We need `-d:debug` to get Nim's default stack traces.
|
2020-07-02 18:40:49 +00:00
|
|
|
NIM_PARAMS += -d:debug
|
2020-07-02 13:20:16 +00:00
|
|
|
|
2020-08-10 16:48:30 +00:00
|
|
|
STATUSGO := vendor/status-go/build/bin/libstatus.$(LIBSTATUS_EXT)
|
|
|
|
|
STATUSGO_LIBDIR := $(shell pwd)/$(shell dirname "$(STATUSGO)")
|
|
|
|
|
export STATUSGO_LIBDIR
|
2020-07-02 13:20:16 +00:00
|
|
|
|
feat: introduce Nim impl of hashMessage in reorganized library
Introduce a Nim implementation of `hashMessage` situated in a reorganized
library with *Nim-oriented* and *C-oriented* entry points inspired by the
[shim strategy][shim-strat] suggested by @arnetheduck.
The goal of this approach (per @iurimatias, at least as I understood what was
discussed and tasked) is for Nim implementations of equivalent functionality to
eventually supersede existing [status-go][sgo] implementations.
These changes will benefit from feedback by @arnetheduck, @zah,
@stefantalpalaru, @siphiuel, other members of stimbus/desktop, et al. – my dev
experiences with Nim and C are quite limited to date. Some of the changes may
be problematic, unnecessary, suboptimal, etc. I may have reified the *"shim
strategy"* badly. Please shred this PR apart and lead me to the 💡
light. Thanks for your help!
N.B. `tests/nim/login.nim` and `tests/c/login.c` use loops that never
terminate (introduced prior to this PR). Future work will attempt to remedy
that shortcoming but it's out of scope for this PR.
The reorganized library can be grouped into two trees of `.nim` sources, but
note that `import` statements interlink some of them.
**Nim-oriented**
```
├── src
│ ├── nim_status
│ │ ├── go
│ │ │ └── shim.nim
│ │ ├── lib
│ │ │ ├── shim.nim
│ │ │ └── util.nim
│ │ ├── lib.nim
│ │ └── types.nim
│ └── nim_status.nim
```
**C-oriented**
```
├── src
│ ├── nim_status
│ │ ├── c
│ │ │ ├── go
│ │ │ │ └── shim.nim
│ │ │ ├── lib
│ │ │ │ └── shim.nim
│ │ │ ├── lib.nim
│ │ │ ├── nim_status.nim
│ │ │ └── sys.nim
```
The key difference between the Nim sources in one tree and the other is that
the Nim-oriented sources are intended to be consumed by other Nim
sources (e.g. [status-im/nim-status-client][nsc] via Nim's built-in `import`),
while the C-oriented sources are intended to be compiled to a C
library (e.g. `nim_status.a`) and then linked/called by other C code. To that
end, the former use e.g. `string` in call signatures while the latter use
`cstring`. Along the same lines, the C-oriented `proc`s may return pointers to
memory allocated with `c_malloc` such that it's up to the caller to free the
memory occupied by the return values.
Both `src/nim_status/go/shim.nim` and `src/nim_status/c/go/shim.nim` are pure
shims around status-go, the main difference being their call signatures.
With `src/nim_status/lib.nim` the intention is to implement functionality in a
manner independent of status-go's idioms.
In `src/nim_status/[c/]lib/shim.nim` the intention is to wrap around
`src/nim_status/lib.nim` in a way that preserves status-go's call signatures
and formatting. For example, the `hashMessage` proc introduced in this PR in
`src/nim_status/lib.nim` returns a hex string like `0xabcd...` while
`lib/shim.nim` returns JSON that's a match for status-go:
`{"result":"0xabcd..."}`.
Both `src/nim_status.nim` and `src/nim_status/c/nim_status.nim` represent a
hybrid of `go/shim.nim` and `lib/shim.nim`. Again, the goal is that over time
more and more `proc`s implemented in Nim replace the shims around status-go.
Callers that don't need to consume return values formatted according to
status-go conventions can use `lib.nim` directly, e.g. via `import
nim_status/lib` or by compiling `src/nim_status/c/lib.nim` and linking/calling
from C.
`c_malloc` has been copied (in `src/nim_status/c/sys.nim`) from the source of
Nim's `system/ansi_c` because `ansi_c` is an undocumented internal API.
A Nim template or pragma might be useful with respect to usgae of `c_malloc` in
`src/nim_status/c/*`, i.e. to cut down on repetition.
Use of `{.exportc.}` is limited to the `src/nim_status/c/nim_status.nim` hybrid
shim to avoid imposing exported symbols on C-oriented library consumers who may
wish to compose things in a different manner.
With respect to the Nim implementation of `hashMessage`, both Nim-oriented and
C-oriented tests have been implemented. Whether doubling up the tests is really
necessary/desirable for all `proc`s is probably worth discussing.
Adjust `.gitignore` and refactor `Makefile` accordingly; apply some lessons
learned while working on [status-im/nim-status-client][nsc].
Closes #34.
[shim-strat]: https://github.com/status-im/nim-status/issues/5#issuecomment-647497745
[sgo]: https://github.com/status-im/status-go
[nsc]: https://github.com/status-im/nim-status-client
2020-07-23 22:15:09 +00:00
|
|
|
status-go: $(STATUSGO)
|
2020-07-02 13:20:16 +00:00
|
|
|
$(STATUSGO): | deps
|
|
|
|
|
echo -e $(BUILD_MSG) "status-go"
|
|
|
|
|
+ cd vendor/status-go && \
|
2020-08-10 16:48:30 +00:00
|
|
|
$(MAKE) statusgo-shared-library $(HANDLE_OUTPUT)
|
2020-07-02 13:20:16 +00:00
|
|
|
|
2020-07-02 18:40:49 +00:00
|
|
|
NIMSTATUS := build/nim_status.a
|
|
|
|
|
|
feat: introduce Nim impl of hashMessage in reorganized library
Introduce a Nim implementation of `hashMessage` situated in a reorganized
library with *Nim-oriented* and *C-oriented* entry points inspired by the
[shim strategy][shim-strat] suggested by @arnetheduck.
The goal of this approach (per @iurimatias, at least as I understood what was
discussed and tasked) is for Nim implementations of equivalent functionality to
eventually supersede existing [status-go][sgo] implementations.
These changes will benefit from feedback by @arnetheduck, @zah,
@stefantalpalaru, @siphiuel, other members of stimbus/desktop, et al. – my dev
experiences with Nim and C are quite limited to date. Some of the changes may
be problematic, unnecessary, suboptimal, etc. I may have reified the *"shim
strategy"* badly. Please shred this PR apart and lead me to the 💡
light. Thanks for your help!
N.B. `tests/nim/login.nim` and `tests/c/login.c` use loops that never
terminate (introduced prior to this PR). Future work will attempt to remedy
that shortcoming but it's out of scope for this PR.
The reorganized library can be grouped into two trees of `.nim` sources, but
note that `import` statements interlink some of them.
**Nim-oriented**
```
├── src
│ ├── nim_status
│ │ ├── go
│ │ │ └── shim.nim
│ │ ├── lib
│ │ │ ├── shim.nim
│ │ │ └── util.nim
│ │ ├── lib.nim
│ │ └── types.nim
│ └── nim_status.nim
```
**C-oriented**
```
├── src
│ ├── nim_status
│ │ ├── c
│ │ │ ├── go
│ │ │ │ └── shim.nim
│ │ │ ├── lib
│ │ │ │ └── shim.nim
│ │ │ ├── lib.nim
│ │ │ ├── nim_status.nim
│ │ │ └── sys.nim
```
The key difference between the Nim sources in one tree and the other is that
the Nim-oriented sources are intended to be consumed by other Nim
sources (e.g. [status-im/nim-status-client][nsc] via Nim's built-in `import`),
while the C-oriented sources are intended to be compiled to a C
library (e.g. `nim_status.a`) and then linked/called by other C code. To that
end, the former use e.g. `string` in call signatures while the latter use
`cstring`. Along the same lines, the C-oriented `proc`s may return pointers to
memory allocated with `c_malloc` such that it's up to the caller to free the
memory occupied by the return values.
Both `src/nim_status/go/shim.nim` and `src/nim_status/c/go/shim.nim` are pure
shims around status-go, the main difference being their call signatures.
With `src/nim_status/lib.nim` the intention is to implement functionality in a
manner independent of status-go's idioms.
In `src/nim_status/[c/]lib/shim.nim` the intention is to wrap around
`src/nim_status/lib.nim` in a way that preserves status-go's call signatures
and formatting. For example, the `hashMessage` proc introduced in this PR in
`src/nim_status/lib.nim` returns a hex string like `0xabcd...` while
`lib/shim.nim` returns JSON that's a match for status-go:
`{"result":"0xabcd..."}`.
Both `src/nim_status.nim` and `src/nim_status/c/nim_status.nim` represent a
hybrid of `go/shim.nim` and `lib/shim.nim`. Again, the goal is that over time
more and more `proc`s implemented in Nim replace the shims around status-go.
Callers that don't need to consume return values formatted according to
status-go conventions can use `lib.nim` directly, e.g. via `import
nim_status/lib` or by compiling `src/nim_status/c/lib.nim` and linking/calling
from C.
`c_malloc` has been copied (in `src/nim_status/c/sys.nim`) from the source of
Nim's `system/ansi_c` because `ansi_c` is an undocumented internal API.
A Nim template or pragma might be useful with respect to usgae of `c_malloc` in
`src/nim_status/c/*`, i.e. to cut down on repetition.
Use of `{.exportc.}` is limited to the `src/nim_status/c/nim_status.nim` hybrid
shim to avoid imposing exported symbols on C-oriented library consumers who may
wish to compose things in a different manner.
With respect to the Nim implementation of `hashMessage`, both Nim-oriented and
C-oriented tests have been implemented. Whether doubling up the tests is really
necessary/desirable for all `proc`s is probably worth discussing.
Adjust `.gitignore` and refactor `Makefile` accordingly; apply some lessons
learned while working on [status-im/nim-status-client][nsc].
Closes #34.
[shim-strat]: https://github.com/status-im/nim-status/issues/5#issuecomment-647497745
[sgo]: https://github.com/status-im/status-go
[nsc]: https://github.com/status-im/nim-status-client
2020-07-23 22:15:09 +00:00
|
|
|
nim_status: | $(NIMSTATUS)
|
|
|
|
|
$(NIMSTATUS): | deps
|
2020-07-02 19:42:07 +00:00
|
|
|
echo -e $(BUILD_MSG) "$@" && \
|
2020-08-10 16:48:30 +00:00
|
|
|
$(ENV_SCRIPT) nim c \
|
|
|
|
|
$(NIM_PARAMS) \
|
|
|
|
|
--app:staticLib \
|
|
|
|
|
--header \
|
|
|
|
|
--noMain \
|
|
|
|
|
-o:$@ \
|
|
|
|
|
src/nim_status/c/nim_status.nim
|
|
|
|
|
cp nimcache/debug/nim_status/nim_status.h build/nim_status.h
|
|
|
|
|
mv nim_status.a build/
|
2020-07-02 18:40:49 +00:00
|
|
|
|
feat: introduce Nim impl of hashMessage in reorganized library
Introduce a Nim implementation of `hashMessage` situated in a reorganized
library with *Nim-oriented* and *C-oriented* entry points inspired by the
[shim strategy][shim-strat] suggested by @arnetheduck.
The goal of this approach (per @iurimatias, at least as I understood what was
discussed and tasked) is for Nim implementations of equivalent functionality to
eventually supersede existing [status-go][sgo] implementations.
These changes will benefit from feedback by @arnetheduck, @zah,
@stefantalpalaru, @siphiuel, other members of stimbus/desktop, et al. – my dev
experiences with Nim and C are quite limited to date. Some of the changes may
be problematic, unnecessary, suboptimal, etc. I may have reified the *"shim
strategy"* badly. Please shred this PR apart and lead me to the 💡
light. Thanks for your help!
N.B. `tests/nim/login.nim` and `tests/c/login.c` use loops that never
terminate (introduced prior to this PR). Future work will attempt to remedy
that shortcoming but it's out of scope for this PR.
The reorganized library can be grouped into two trees of `.nim` sources, but
note that `import` statements interlink some of them.
**Nim-oriented**
```
├── src
│ ├── nim_status
│ │ ├── go
│ │ │ └── shim.nim
│ │ ├── lib
│ │ │ ├── shim.nim
│ │ │ └── util.nim
│ │ ├── lib.nim
│ │ └── types.nim
│ └── nim_status.nim
```
**C-oriented**
```
├── src
│ ├── nim_status
│ │ ├── c
│ │ │ ├── go
│ │ │ │ └── shim.nim
│ │ │ ├── lib
│ │ │ │ └── shim.nim
│ │ │ ├── lib.nim
│ │ │ ├── nim_status.nim
│ │ │ └── sys.nim
```
The key difference between the Nim sources in one tree and the other is that
the Nim-oriented sources are intended to be consumed by other Nim
sources (e.g. [status-im/nim-status-client][nsc] via Nim's built-in `import`),
while the C-oriented sources are intended to be compiled to a C
library (e.g. `nim_status.a`) and then linked/called by other C code. To that
end, the former use e.g. `string` in call signatures while the latter use
`cstring`. Along the same lines, the C-oriented `proc`s may return pointers to
memory allocated with `c_malloc` such that it's up to the caller to free the
memory occupied by the return values.
Both `src/nim_status/go/shim.nim` and `src/nim_status/c/go/shim.nim` are pure
shims around status-go, the main difference being their call signatures.
With `src/nim_status/lib.nim` the intention is to implement functionality in a
manner independent of status-go's idioms.
In `src/nim_status/[c/]lib/shim.nim` the intention is to wrap around
`src/nim_status/lib.nim` in a way that preserves status-go's call signatures
and formatting. For example, the `hashMessage` proc introduced in this PR in
`src/nim_status/lib.nim` returns a hex string like `0xabcd...` while
`lib/shim.nim` returns JSON that's a match for status-go:
`{"result":"0xabcd..."}`.
Both `src/nim_status.nim` and `src/nim_status/c/nim_status.nim` represent a
hybrid of `go/shim.nim` and `lib/shim.nim`. Again, the goal is that over time
more and more `proc`s implemented in Nim replace the shims around status-go.
Callers that don't need to consume return values formatted according to
status-go conventions can use `lib.nim` directly, e.g. via `import
nim_status/lib` or by compiling `src/nim_status/c/lib.nim` and linking/calling
from C.
`c_malloc` has been copied (in `src/nim_status/c/sys.nim`) from the source of
Nim's `system/ansi_c` because `ansi_c` is an undocumented internal API.
A Nim template or pragma might be useful with respect to usgae of `c_malloc` in
`src/nim_status/c/*`, i.e. to cut down on repetition.
Use of `{.exportc.}` is limited to the `src/nim_status/c/nim_status.nim` hybrid
shim to avoid imposing exported symbols on C-oriented library consumers who may
wish to compose things in a different manner.
With respect to the Nim implementation of `hashMessage`, both Nim-oriented and
C-oriented tests have been implemented. Whether doubling up the tests is really
necessary/desirable for all `proc`s is probably worth discussing.
Adjust `.gitignore` and refactor `Makefile` accordingly; apply some lessons
learned while working on [status-im/nim-status-client][nsc].
Closes #34.
[shim-strat]: https://github.com/status-im/nim-status/issues/5#issuecomment-647497745
[sgo]: https://github.com/status-im/status-go
[nsc]: https://github.com/status-im/nim-status-client
2020-07-23 22:15:09 +00:00
|
|
|
SHIMS := tests/c/build/shims.a
|
2020-07-02 18:40:49 +00:00
|
|
|
|
feat: introduce Nim impl of hashMessage in reorganized library
Introduce a Nim implementation of `hashMessage` situated in a reorganized
library with *Nim-oriented* and *C-oriented* entry points inspired by the
[shim strategy][shim-strat] suggested by @arnetheduck.
The goal of this approach (per @iurimatias, at least as I understood what was
discussed and tasked) is for Nim implementations of equivalent functionality to
eventually supersede existing [status-go][sgo] implementations.
These changes will benefit from feedback by @arnetheduck, @zah,
@stefantalpalaru, @siphiuel, other members of stimbus/desktop, et al. – my dev
experiences with Nim and C are quite limited to date. Some of the changes may
be problematic, unnecessary, suboptimal, etc. I may have reified the *"shim
strategy"* badly. Please shred this PR apart and lead me to the 💡
light. Thanks for your help!
N.B. `tests/nim/login.nim` and `tests/c/login.c` use loops that never
terminate (introduced prior to this PR). Future work will attempt to remedy
that shortcoming but it's out of scope for this PR.
The reorganized library can be grouped into two trees of `.nim` sources, but
note that `import` statements interlink some of them.
**Nim-oriented**
```
├── src
│ ├── nim_status
│ │ ├── go
│ │ │ └── shim.nim
│ │ ├── lib
│ │ │ ├── shim.nim
│ │ │ └── util.nim
│ │ ├── lib.nim
│ │ └── types.nim
│ └── nim_status.nim
```
**C-oriented**
```
├── src
│ ├── nim_status
│ │ ├── c
│ │ │ ├── go
│ │ │ │ └── shim.nim
│ │ │ ├── lib
│ │ │ │ └── shim.nim
│ │ │ ├── lib.nim
│ │ │ ├── nim_status.nim
│ │ │ └── sys.nim
```
The key difference between the Nim sources in one tree and the other is that
the Nim-oriented sources are intended to be consumed by other Nim
sources (e.g. [status-im/nim-status-client][nsc] via Nim's built-in `import`),
while the C-oriented sources are intended to be compiled to a C
library (e.g. `nim_status.a`) and then linked/called by other C code. To that
end, the former use e.g. `string` in call signatures while the latter use
`cstring`. Along the same lines, the C-oriented `proc`s may return pointers to
memory allocated with `c_malloc` such that it's up to the caller to free the
memory occupied by the return values.
Both `src/nim_status/go/shim.nim` and `src/nim_status/c/go/shim.nim` are pure
shims around status-go, the main difference being their call signatures.
With `src/nim_status/lib.nim` the intention is to implement functionality in a
manner independent of status-go's idioms.
In `src/nim_status/[c/]lib/shim.nim` the intention is to wrap around
`src/nim_status/lib.nim` in a way that preserves status-go's call signatures
and formatting. For example, the `hashMessage` proc introduced in this PR in
`src/nim_status/lib.nim` returns a hex string like `0xabcd...` while
`lib/shim.nim` returns JSON that's a match for status-go:
`{"result":"0xabcd..."}`.
Both `src/nim_status.nim` and `src/nim_status/c/nim_status.nim` represent a
hybrid of `go/shim.nim` and `lib/shim.nim`. Again, the goal is that over time
more and more `proc`s implemented in Nim replace the shims around status-go.
Callers that don't need to consume return values formatted according to
status-go conventions can use `lib.nim` directly, e.g. via `import
nim_status/lib` or by compiling `src/nim_status/c/lib.nim` and linking/calling
from C.
`c_malloc` has been copied (in `src/nim_status/c/sys.nim`) from the source of
Nim's `system/ansi_c` because `ansi_c` is an undocumented internal API.
A Nim template or pragma might be useful with respect to usgae of `c_malloc` in
`src/nim_status/c/*`, i.e. to cut down on repetition.
Use of `{.exportc.}` is limited to the `src/nim_status/c/nim_status.nim` hybrid
shim to avoid imposing exported symbols on C-oriented library consumers who may
wish to compose things in a different manner.
With respect to the Nim implementation of `hashMessage`, both Nim-oriented and
C-oriented tests have been implemented. Whether doubling up the tests is really
necessary/desirable for all `proc`s is probably worth discussing.
Adjust `.gitignore` and refactor `Makefile` accordingly; apply some lessons
learned while working on [status-im/nim-status-client][nsc].
Closes #34.
[shim-strat]: https://github.com/status-im/nim-status/issues/5#issuecomment-647497745
[sgo]: https://github.com/status-im/status-go
[nsc]: https://github.com/status-im/nim-status-client
2020-07-23 22:15:09 +00:00
|
|
|
shims: | $(SHIMS)
|
|
|
|
|
$(SHIMS): | deps
|
|
|
|
|
echo -e $(BUILD_MSG) "$@" && \
|
2020-08-10 16:48:30 +00:00
|
|
|
$(ENV_SCRIPT) nim c \
|
|
|
|
|
$(NIM_PARAMS) \
|
|
|
|
|
--app:staticLib \
|
|
|
|
|
--header \
|
|
|
|
|
--noMain \
|
|
|
|
|
-o:$@ \
|
|
|
|
|
tests/c/shims.nim
|
|
|
|
|
cp nimcache/debug/shims/shims.h tests/c/build/shims.h
|
feat: introduce Nim impl of hashMessage in reorganized library
Introduce a Nim implementation of `hashMessage` situated in a reorganized
library with *Nim-oriented* and *C-oriented* entry points inspired by the
[shim strategy][shim-strat] suggested by @arnetheduck.
The goal of this approach (per @iurimatias, at least as I understood what was
discussed and tasked) is for Nim implementations of equivalent functionality to
eventually supersede existing [status-go][sgo] implementations.
These changes will benefit from feedback by @arnetheduck, @zah,
@stefantalpalaru, @siphiuel, other members of stimbus/desktop, et al. – my dev
experiences with Nim and C are quite limited to date. Some of the changes may
be problematic, unnecessary, suboptimal, etc. I may have reified the *"shim
strategy"* badly. Please shred this PR apart and lead me to the 💡
light. Thanks for your help!
N.B. `tests/nim/login.nim` and `tests/c/login.c` use loops that never
terminate (introduced prior to this PR). Future work will attempt to remedy
that shortcoming but it's out of scope for this PR.
The reorganized library can be grouped into two trees of `.nim` sources, but
note that `import` statements interlink some of them.
**Nim-oriented**
```
├── src
│ ├── nim_status
│ │ ├── go
│ │ │ └── shim.nim
│ │ ├── lib
│ │ │ ├── shim.nim
│ │ │ └── util.nim
│ │ ├── lib.nim
│ │ └── types.nim
│ └── nim_status.nim
```
**C-oriented**
```
├── src
│ ├── nim_status
│ │ ├── c
│ │ │ ├── go
│ │ │ │ └── shim.nim
│ │ │ ├── lib
│ │ │ │ └── shim.nim
│ │ │ ├── lib.nim
│ │ │ ├── nim_status.nim
│ │ │ └── sys.nim
```
The key difference between the Nim sources in one tree and the other is that
the Nim-oriented sources are intended to be consumed by other Nim
sources (e.g. [status-im/nim-status-client][nsc] via Nim's built-in `import`),
while the C-oriented sources are intended to be compiled to a C
library (e.g. `nim_status.a`) and then linked/called by other C code. To that
end, the former use e.g. `string` in call signatures while the latter use
`cstring`. Along the same lines, the C-oriented `proc`s may return pointers to
memory allocated with `c_malloc` such that it's up to the caller to free the
memory occupied by the return values.
Both `src/nim_status/go/shim.nim` and `src/nim_status/c/go/shim.nim` are pure
shims around status-go, the main difference being their call signatures.
With `src/nim_status/lib.nim` the intention is to implement functionality in a
manner independent of status-go's idioms.
In `src/nim_status/[c/]lib/shim.nim` the intention is to wrap around
`src/nim_status/lib.nim` in a way that preserves status-go's call signatures
and formatting. For example, the `hashMessage` proc introduced in this PR in
`src/nim_status/lib.nim` returns a hex string like `0xabcd...` while
`lib/shim.nim` returns JSON that's a match for status-go:
`{"result":"0xabcd..."}`.
Both `src/nim_status.nim` and `src/nim_status/c/nim_status.nim` represent a
hybrid of `go/shim.nim` and `lib/shim.nim`. Again, the goal is that over time
more and more `proc`s implemented in Nim replace the shims around status-go.
Callers that don't need to consume return values formatted according to
status-go conventions can use `lib.nim` directly, e.g. via `import
nim_status/lib` or by compiling `src/nim_status/c/lib.nim` and linking/calling
from C.
`c_malloc` has been copied (in `src/nim_status/c/sys.nim`) from the source of
Nim's `system/ansi_c` because `ansi_c` is an undocumented internal API.
A Nim template or pragma might be useful with respect to usgae of `c_malloc` in
`src/nim_status/c/*`, i.e. to cut down on repetition.
Use of `{.exportc.}` is limited to the `src/nim_status/c/nim_status.nim` hybrid
shim to avoid imposing exported symbols on C-oriented library consumers who may
wish to compose things in a different manner.
With respect to the Nim implementation of `hashMessage`, both Nim-oriented and
C-oriented tests have been implemented. Whether doubling up the tests is really
necessary/desirable for all `proc`s is probably worth discussing.
Adjust `.gitignore` and refactor `Makefile` accordingly; apply some lessons
learned while working on [status-im/nim-status-client][nsc].
Closes #34.
[shim-strat]: https://github.com/status-im/nim-status/issues/5#issuecomment-647497745
[sgo]: https://github.com/status-im/status-go
[nsc]: https://github.com/status-im/nim-status-client
2020-07-23 22:15:09 +00:00
|
|
|
mv shims.a tests/c/build/
|
|
|
|
|
|
2020-08-10 16:48:30 +00:00
|
|
|
test-c-template: | $(STATUSGO) clean-data-dirs create-data-dirs
|
feat: introduce Nim impl of hashMessage in reorganized library
Introduce a Nim implementation of `hashMessage` situated in a reorganized
library with *Nim-oriented* and *C-oriented* entry points inspired by the
[shim strategy][shim-strat] suggested by @arnetheduck.
The goal of this approach (per @iurimatias, at least as I understood what was
discussed and tasked) is for Nim implementations of equivalent functionality to
eventually supersede existing [status-go][sgo] implementations.
These changes will benefit from feedback by @arnetheduck, @zah,
@stefantalpalaru, @siphiuel, other members of stimbus/desktop, et al. – my dev
experiences with Nim and C are quite limited to date. Some of the changes may
be problematic, unnecessary, suboptimal, etc. I may have reified the *"shim
strategy"* badly. Please shred this PR apart and lead me to the 💡
light. Thanks for your help!
N.B. `tests/nim/login.nim` and `tests/c/login.c` use loops that never
terminate (introduced prior to this PR). Future work will attempt to remedy
that shortcoming but it's out of scope for this PR.
The reorganized library can be grouped into two trees of `.nim` sources, but
note that `import` statements interlink some of them.
**Nim-oriented**
```
├── src
│ ├── nim_status
│ │ ├── go
│ │ │ └── shim.nim
│ │ ├── lib
│ │ │ ├── shim.nim
│ │ │ └── util.nim
│ │ ├── lib.nim
│ │ └── types.nim
│ └── nim_status.nim
```
**C-oriented**
```
├── src
│ ├── nim_status
│ │ ├── c
│ │ │ ├── go
│ │ │ │ └── shim.nim
│ │ │ ├── lib
│ │ │ │ └── shim.nim
│ │ │ ├── lib.nim
│ │ │ ├── nim_status.nim
│ │ │ └── sys.nim
```
The key difference between the Nim sources in one tree and the other is that
the Nim-oriented sources are intended to be consumed by other Nim
sources (e.g. [status-im/nim-status-client][nsc] via Nim's built-in `import`),
while the C-oriented sources are intended to be compiled to a C
library (e.g. `nim_status.a`) and then linked/called by other C code. To that
end, the former use e.g. `string` in call signatures while the latter use
`cstring`. Along the same lines, the C-oriented `proc`s may return pointers to
memory allocated with `c_malloc` such that it's up to the caller to free the
memory occupied by the return values.
Both `src/nim_status/go/shim.nim` and `src/nim_status/c/go/shim.nim` are pure
shims around status-go, the main difference being their call signatures.
With `src/nim_status/lib.nim` the intention is to implement functionality in a
manner independent of status-go's idioms.
In `src/nim_status/[c/]lib/shim.nim` the intention is to wrap around
`src/nim_status/lib.nim` in a way that preserves status-go's call signatures
and formatting. For example, the `hashMessage` proc introduced in this PR in
`src/nim_status/lib.nim` returns a hex string like `0xabcd...` while
`lib/shim.nim` returns JSON that's a match for status-go:
`{"result":"0xabcd..."}`.
Both `src/nim_status.nim` and `src/nim_status/c/nim_status.nim` represent a
hybrid of `go/shim.nim` and `lib/shim.nim`. Again, the goal is that over time
more and more `proc`s implemented in Nim replace the shims around status-go.
Callers that don't need to consume return values formatted according to
status-go conventions can use `lib.nim` directly, e.g. via `import
nim_status/lib` or by compiling `src/nim_status/c/lib.nim` and linking/calling
from C.
`c_malloc` has been copied (in `src/nim_status/c/sys.nim`) from the source of
Nim's `system/ansi_c` because `ansi_c` is an undocumented internal API.
A Nim template or pragma might be useful with respect to usgae of `c_malloc` in
`src/nim_status/c/*`, i.e. to cut down on repetition.
Use of `{.exportc.}` is limited to the `src/nim_status/c/nim_status.nim` hybrid
shim to avoid imposing exported symbols on C-oriented library consumers who may
wish to compose things in a different manner.
With respect to the Nim implementation of `hashMessage`, both Nim-oriented and
C-oriented tests have been implemented. Whether doubling up the tests is really
necessary/desirable for all `proc`s is probably worth discussing.
Adjust `.gitignore` and refactor `Makefile` accordingly; apply some lessons
learned while working on [status-im/nim-status-client][nsc].
Closes #34.
[shim-strat]: https://github.com/status-im/nim-status/issues/5#issuecomment-647497745
[sgo]: https://github.com/status-im/status-go
[nsc]: https://github.com/status-im/nim-status-client
2020-07-23 22:15:09 +00:00
|
|
|
mkdir -p tests/c/build
|
2020-08-10 16:48:30 +00:00
|
|
|
echo "Compiling 'tests/c/$(TEST_NAME)'"
|
|
|
|
|
$(ENV_SCRIPT) $(CC) \
|
|
|
|
|
$(TEST_INCLUDES) \
|
|
|
|
|
-I"$(CURDIR)/vendor/nimbus-build-system/vendor/Nim/lib" \
|
|
|
|
|
tests/c/$(TEST_NAME).c \
|
|
|
|
|
$(TEST_DEPS) \
|
|
|
|
|
$(NIM_DEP_LIBS) \
|
|
|
|
|
-L$(STATUSGO_LIBDIR) \
|
|
|
|
|
-lstatus \
|
|
|
|
|
$(FRAMEWORKS) \
|
|
|
|
|
-lm \
|
|
|
|
|
-pthread \
|
|
|
|
|
-o tests/c/build/$(TEST_NAME)
|
|
|
|
|
[[ $(detected_OS) = Darwin ]] && \
|
|
|
|
|
install_name_tool -add_rpath \
|
|
|
|
|
"$(STATUSGO_LIBDIR)" \
|
|
|
|
|
tests/c/build/$(TEST_NAME) && \
|
|
|
|
|
install_name_tool -change \
|
|
|
|
|
libstatus.dylib \
|
|
|
|
|
@rpath/libstatus.dylib \
|
|
|
|
|
tests/c/build/$(TEST_NAME) || true
|
|
|
|
|
echo "Executing 'tests/c/build/$(TEST_NAME)'"
|
feat: introduce Nim impl of hashMessage in reorganized library
Introduce a Nim implementation of `hashMessage` situated in a reorganized
library with *Nim-oriented* and *C-oriented* entry points inspired by the
[shim strategy][shim-strat] suggested by @arnetheduck.
The goal of this approach (per @iurimatias, at least as I understood what was
discussed and tasked) is for Nim implementations of equivalent functionality to
eventually supersede existing [status-go][sgo] implementations.
These changes will benefit from feedback by @arnetheduck, @zah,
@stefantalpalaru, @siphiuel, other members of stimbus/desktop, et al. – my dev
experiences with Nim and C are quite limited to date. Some of the changes may
be problematic, unnecessary, suboptimal, etc. I may have reified the *"shim
strategy"* badly. Please shred this PR apart and lead me to the 💡
light. Thanks for your help!
N.B. `tests/nim/login.nim` and `tests/c/login.c` use loops that never
terminate (introduced prior to this PR). Future work will attempt to remedy
that shortcoming but it's out of scope for this PR.
The reorganized library can be grouped into two trees of `.nim` sources, but
note that `import` statements interlink some of them.
**Nim-oriented**
```
├── src
│ ├── nim_status
│ │ ├── go
│ │ │ └── shim.nim
│ │ ├── lib
│ │ │ ├── shim.nim
│ │ │ └── util.nim
│ │ ├── lib.nim
│ │ └── types.nim
│ └── nim_status.nim
```
**C-oriented**
```
├── src
│ ├── nim_status
│ │ ├── c
│ │ │ ├── go
│ │ │ │ └── shim.nim
│ │ │ ├── lib
│ │ │ │ └── shim.nim
│ │ │ ├── lib.nim
│ │ │ ├── nim_status.nim
│ │ │ └── sys.nim
```
The key difference between the Nim sources in one tree and the other is that
the Nim-oriented sources are intended to be consumed by other Nim
sources (e.g. [status-im/nim-status-client][nsc] via Nim's built-in `import`),
while the C-oriented sources are intended to be compiled to a C
library (e.g. `nim_status.a`) and then linked/called by other C code. To that
end, the former use e.g. `string` in call signatures while the latter use
`cstring`. Along the same lines, the C-oriented `proc`s may return pointers to
memory allocated with `c_malloc` such that it's up to the caller to free the
memory occupied by the return values.
Both `src/nim_status/go/shim.nim` and `src/nim_status/c/go/shim.nim` are pure
shims around status-go, the main difference being their call signatures.
With `src/nim_status/lib.nim` the intention is to implement functionality in a
manner independent of status-go's idioms.
In `src/nim_status/[c/]lib/shim.nim` the intention is to wrap around
`src/nim_status/lib.nim` in a way that preserves status-go's call signatures
and formatting. For example, the `hashMessage` proc introduced in this PR in
`src/nim_status/lib.nim` returns a hex string like `0xabcd...` while
`lib/shim.nim` returns JSON that's a match for status-go:
`{"result":"0xabcd..."}`.
Both `src/nim_status.nim` and `src/nim_status/c/nim_status.nim` represent a
hybrid of `go/shim.nim` and `lib/shim.nim`. Again, the goal is that over time
more and more `proc`s implemented in Nim replace the shims around status-go.
Callers that don't need to consume return values formatted according to
status-go conventions can use `lib.nim` directly, e.g. via `import
nim_status/lib` or by compiling `src/nim_status/c/lib.nim` and linking/calling
from C.
`c_malloc` has been copied (in `src/nim_status/c/sys.nim`) from the source of
Nim's `system/ansi_c` because `ansi_c` is an undocumented internal API.
A Nim template or pragma might be useful with respect to usgae of `c_malloc` in
`src/nim_status/c/*`, i.e. to cut down on repetition.
Use of `{.exportc.}` is limited to the `src/nim_status/c/nim_status.nim` hybrid
shim to avoid imposing exported symbols on C-oriented library consumers who may
wish to compose things in a different manner.
With respect to the Nim implementation of `hashMessage`, both Nim-oriented and
C-oriented tests have been implemented. Whether doubling up the tests is really
necessary/desirable for all `proc`s is probably worth discussing.
Adjust `.gitignore` and refactor `Makefile` accordingly; apply some lessons
learned while working on [status-im/nim-status-client][nsc].
Closes #34.
[shim-strat]: https://github.com/status-im/nim-status/issues/5#issuecomment-647497745
[sgo]: https://github.com/status-im/status-go
[nsc]: https://github.com/status-im/nim-status-client
2020-07-23 22:15:09 +00:00
|
|
|
ifeq ($(detected_OS),Darwin)
|
2020-08-10 16:48:30 +00:00
|
|
|
./tests/c/build/$(TEST_NAME)
|
|
|
|
|
else ifeq ($(detected_OS),Windows)
|
2020-09-01 22:53:17 +00:00
|
|
|
PATH="$(STATUSGO_LIBDIR):$(NIM_WINDOWS_PREBUILT_DLLDIR):/usr/bin:/bin:$$PATH" \
|
2020-08-10 16:48:30 +00:00
|
|
|
./tests/c/build/$(TEST_NAME)
|
2020-07-03 12:28:12 +00:00
|
|
|
else
|
2020-08-10 16:48:30 +00:00
|
|
|
LD_LIBRARY_PATH="$(STATUSGO_LIBDIR)" \
|
|
|
|
|
./tests/c/build/$(TEST_NAME)
|
2020-07-03 12:28:12 +00:00
|
|
|
endif
|
feat: introduce Nim impl of hashMessage in reorganized library
Introduce a Nim implementation of `hashMessage` situated in a reorganized
library with *Nim-oriented* and *C-oriented* entry points inspired by the
[shim strategy][shim-strat] suggested by @arnetheduck.
The goal of this approach (per @iurimatias, at least as I understood what was
discussed and tasked) is for Nim implementations of equivalent functionality to
eventually supersede existing [status-go][sgo] implementations.
These changes will benefit from feedback by @arnetheduck, @zah,
@stefantalpalaru, @siphiuel, other members of stimbus/desktop, et al. – my dev
experiences with Nim and C are quite limited to date. Some of the changes may
be problematic, unnecessary, suboptimal, etc. I may have reified the *"shim
strategy"* badly. Please shred this PR apart and lead me to the 💡
light. Thanks for your help!
N.B. `tests/nim/login.nim` and `tests/c/login.c` use loops that never
terminate (introduced prior to this PR). Future work will attempt to remedy
that shortcoming but it's out of scope for this PR.
The reorganized library can be grouped into two trees of `.nim` sources, but
note that `import` statements interlink some of them.
**Nim-oriented**
```
├── src
│ ├── nim_status
│ │ ├── go
│ │ │ └── shim.nim
│ │ ├── lib
│ │ │ ├── shim.nim
│ │ │ └── util.nim
│ │ ├── lib.nim
│ │ └── types.nim
│ └── nim_status.nim
```
**C-oriented**
```
├── src
│ ├── nim_status
│ │ ├── c
│ │ │ ├── go
│ │ │ │ └── shim.nim
│ │ │ ├── lib
│ │ │ │ └── shim.nim
│ │ │ ├── lib.nim
│ │ │ ├── nim_status.nim
│ │ │ └── sys.nim
```
The key difference between the Nim sources in one tree and the other is that
the Nim-oriented sources are intended to be consumed by other Nim
sources (e.g. [status-im/nim-status-client][nsc] via Nim's built-in `import`),
while the C-oriented sources are intended to be compiled to a C
library (e.g. `nim_status.a`) and then linked/called by other C code. To that
end, the former use e.g. `string` in call signatures while the latter use
`cstring`. Along the same lines, the C-oriented `proc`s may return pointers to
memory allocated with `c_malloc` such that it's up to the caller to free the
memory occupied by the return values.
Both `src/nim_status/go/shim.nim` and `src/nim_status/c/go/shim.nim` are pure
shims around status-go, the main difference being their call signatures.
With `src/nim_status/lib.nim` the intention is to implement functionality in a
manner independent of status-go's idioms.
In `src/nim_status/[c/]lib/shim.nim` the intention is to wrap around
`src/nim_status/lib.nim` in a way that preserves status-go's call signatures
and formatting. For example, the `hashMessage` proc introduced in this PR in
`src/nim_status/lib.nim` returns a hex string like `0xabcd...` while
`lib/shim.nim` returns JSON that's a match for status-go:
`{"result":"0xabcd..."}`.
Both `src/nim_status.nim` and `src/nim_status/c/nim_status.nim` represent a
hybrid of `go/shim.nim` and `lib/shim.nim`. Again, the goal is that over time
more and more `proc`s implemented in Nim replace the shims around status-go.
Callers that don't need to consume return values formatted according to
status-go conventions can use `lib.nim` directly, e.g. via `import
nim_status/lib` or by compiling `src/nim_status/c/lib.nim` and linking/calling
from C.
`c_malloc` has been copied (in `src/nim_status/c/sys.nim`) from the source of
Nim's `system/ansi_c` because `ansi_c` is an undocumented internal API.
A Nim template or pragma might be useful with respect to usgae of `c_malloc` in
`src/nim_status/c/*`, i.e. to cut down on repetition.
Use of `{.exportc.}` is limited to the `src/nim_status/c/nim_status.nim` hybrid
shim to avoid imposing exported symbols on C-oriented library consumers who may
wish to compose things in a different manner.
With respect to the Nim implementation of `hashMessage`, both Nim-oriented and
C-oriented tests have been implemented. Whether doubling up the tests is really
necessary/desirable for all `proc`s is probably worth discussing.
Adjust `.gitignore` and refactor `Makefile` accordingly; apply some lessons
learned while working on [status-im/nim-status-client][nsc].
Closes #34.
[shim-strat]: https://github.com/status-im/nim-status/issues/5#issuecomment-647497745
[sgo]: https://github.com/status-im/status-go
[nsc]: https://github.com/status-im/nim-status-client
2020-07-23 22:15:09 +00:00
|
|
|
|
2020-08-10 16:48:30 +00:00
|
|
|
SHIMS_INCLUDES := -I\"$(CURDIR)/tests/c/build\"
|
|
|
|
|
|
|
|
|
|
test-c-shims: | $(SHIMS)
|
|
|
|
|
$(MAKE) TEST_DEPS=$(SHIMS) \
|
|
|
|
|
TEST_INCLUDES=$(SHIMS_INCLUDES) \
|
|
|
|
|
TEST_NAME=shims \
|
|
|
|
|
test-c-template
|
|
|
|
|
|
|
|
|
|
LOGIN_INCLUDES := -I\"$(CURDIR)/build\"
|
|
|
|
|
|
|
|
|
|
test-c-login: | $(NIMSTATUS)
|
|
|
|
|
$(MAKE) TEST_DEPS=$(NIMSTATUS) \
|
|
|
|
|
TEST_INCLUDES=$(LOGIN_INCLUDES) \
|
|
|
|
|
TEST_NAME=login \
|
|
|
|
|
test-c-template
|
feat: introduce Nim impl of hashMessage in reorganized library
Introduce a Nim implementation of `hashMessage` situated in a reorganized
library with *Nim-oriented* and *C-oriented* entry points inspired by the
[shim strategy][shim-strat] suggested by @arnetheduck.
The goal of this approach (per @iurimatias, at least as I understood what was
discussed and tasked) is for Nim implementations of equivalent functionality to
eventually supersede existing [status-go][sgo] implementations.
These changes will benefit from feedback by @arnetheduck, @zah,
@stefantalpalaru, @siphiuel, other members of stimbus/desktop, et al. – my dev
experiences with Nim and C are quite limited to date. Some of the changes may
be problematic, unnecessary, suboptimal, etc. I may have reified the *"shim
strategy"* badly. Please shred this PR apart and lead me to the 💡
light. Thanks for your help!
N.B. `tests/nim/login.nim` and `tests/c/login.c` use loops that never
terminate (introduced prior to this PR). Future work will attempt to remedy
that shortcoming but it's out of scope for this PR.
The reorganized library can be grouped into two trees of `.nim` sources, but
note that `import` statements interlink some of them.
**Nim-oriented**
```
├── src
│ ├── nim_status
│ │ ├── go
│ │ │ └── shim.nim
│ │ ├── lib
│ │ │ ├── shim.nim
│ │ │ └── util.nim
│ │ ├── lib.nim
│ │ └── types.nim
│ └── nim_status.nim
```
**C-oriented**
```
├── src
│ ├── nim_status
│ │ ├── c
│ │ │ ├── go
│ │ │ │ └── shim.nim
│ │ │ ├── lib
│ │ │ │ └── shim.nim
│ │ │ ├── lib.nim
│ │ │ ├── nim_status.nim
│ │ │ └── sys.nim
```
The key difference between the Nim sources in one tree and the other is that
the Nim-oriented sources are intended to be consumed by other Nim
sources (e.g. [status-im/nim-status-client][nsc] via Nim's built-in `import`),
while the C-oriented sources are intended to be compiled to a C
library (e.g. `nim_status.a`) and then linked/called by other C code. To that
end, the former use e.g. `string` in call signatures while the latter use
`cstring`. Along the same lines, the C-oriented `proc`s may return pointers to
memory allocated with `c_malloc` such that it's up to the caller to free the
memory occupied by the return values.
Both `src/nim_status/go/shim.nim` and `src/nim_status/c/go/shim.nim` are pure
shims around status-go, the main difference being their call signatures.
With `src/nim_status/lib.nim` the intention is to implement functionality in a
manner independent of status-go's idioms.
In `src/nim_status/[c/]lib/shim.nim` the intention is to wrap around
`src/nim_status/lib.nim` in a way that preserves status-go's call signatures
and formatting. For example, the `hashMessage` proc introduced in this PR in
`src/nim_status/lib.nim` returns a hex string like `0xabcd...` while
`lib/shim.nim` returns JSON that's a match for status-go:
`{"result":"0xabcd..."}`.
Both `src/nim_status.nim` and `src/nim_status/c/nim_status.nim` represent a
hybrid of `go/shim.nim` and `lib/shim.nim`. Again, the goal is that over time
more and more `proc`s implemented in Nim replace the shims around status-go.
Callers that don't need to consume return values formatted according to
status-go conventions can use `lib.nim` directly, e.g. via `import
nim_status/lib` or by compiling `src/nim_status/c/lib.nim` and linking/calling
from C.
`c_malloc` has been copied (in `src/nim_status/c/sys.nim`) from the source of
Nim's `system/ansi_c` because `ansi_c` is an undocumented internal API.
A Nim template or pragma might be useful with respect to usgae of `c_malloc` in
`src/nim_status/c/*`, i.e. to cut down on repetition.
Use of `{.exportc.}` is limited to the `src/nim_status/c/nim_status.nim` hybrid
shim to avoid imposing exported symbols on C-oriented library consumers who may
wish to compose things in a different manner.
With respect to the Nim implementation of `hashMessage`, both Nim-oriented and
C-oriented tests have been implemented. Whether doubling up the tests is really
necessary/desirable for all `proc`s is probably worth discussing.
Adjust `.gitignore` and refactor `Makefile` accordingly; apply some lessons
learned while working on [status-im/nim-status-client][nsc].
Closes #34.
[shim-strat]: https://github.com/status-im/nim-status/issues/5#issuecomment-647497745
[sgo]: https://github.com/status-im/status-go
[nsc]: https://github.com/status-im/nim-status-client
2020-07-23 22:15:09 +00:00
|
|
|
|
|
|
|
|
tests-c:
|
2020-08-10 16:48:30 +00:00
|
|
|
$(MAKE) test-c-shims
|
|
|
|
|
$(MAKE) test-c-login
|
2020-07-13 14:26:31 +00:00
|
|
|
|
feat: introduce Nim impl of hashMessage in reorganized library
Introduce a Nim implementation of `hashMessage` situated in a reorganized
library with *Nim-oriented* and *C-oriented* entry points inspired by the
[shim strategy][shim-strat] suggested by @arnetheduck.
The goal of this approach (per @iurimatias, at least as I understood what was
discussed and tasked) is for Nim implementations of equivalent functionality to
eventually supersede existing [status-go][sgo] implementations.
These changes will benefit from feedback by @arnetheduck, @zah,
@stefantalpalaru, @siphiuel, other members of stimbus/desktop, et al. – my dev
experiences with Nim and C are quite limited to date. Some of the changes may
be problematic, unnecessary, suboptimal, etc. I may have reified the *"shim
strategy"* badly. Please shred this PR apart and lead me to the 💡
light. Thanks for your help!
N.B. `tests/nim/login.nim` and `tests/c/login.c` use loops that never
terminate (introduced prior to this PR). Future work will attempt to remedy
that shortcoming but it's out of scope for this PR.
The reorganized library can be grouped into two trees of `.nim` sources, but
note that `import` statements interlink some of them.
**Nim-oriented**
```
├── src
│ ├── nim_status
│ │ ├── go
│ │ │ └── shim.nim
│ │ ├── lib
│ │ │ ├── shim.nim
│ │ │ └── util.nim
│ │ ├── lib.nim
│ │ └── types.nim
│ └── nim_status.nim
```
**C-oriented**
```
├── src
│ ├── nim_status
│ │ ├── c
│ │ │ ├── go
│ │ │ │ └── shim.nim
│ │ │ ├── lib
│ │ │ │ └── shim.nim
│ │ │ ├── lib.nim
│ │ │ ├── nim_status.nim
│ │ │ └── sys.nim
```
The key difference between the Nim sources in one tree and the other is that
the Nim-oriented sources are intended to be consumed by other Nim
sources (e.g. [status-im/nim-status-client][nsc] via Nim's built-in `import`),
while the C-oriented sources are intended to be compiled to a C
library (e.g. `nim_status.a`) and then linked/called by other C code. To that
end, the former use e.g. `string` in call signatures while the latter use
`cstring`. Along the same lines, the C-oriented `proc`s may return pointers to
memory allocated with `c_malloc` such that it's up to the caller to free the
memory occupied by the return values.
Both `src/nim_status/go/shim.nim` and `src/nim_status/c/go/shim.nim` are pure
shims around status-go, the main difference being their call signatures.
With `src/nim_status/lib.nim` the intention is to implement functionality in a
manner independent of status-go's idioms.
In `src/nim_status/[c/]lib/shim.nim` the intention is to wrap around
`src/nim_status/lib.nim` in a way that preserves status-go's call signatures
and formatting. For example, the `hashMessage` proc introduced in this PR in
`src/nim_status/lib.nim` returns a hex string like `0xabcd...` while
`lib/shim.nim` returns JSON that's a match for status-go:
`{"result":"0xabcd..."}`.
Both `src/nim_status.nim` and `src/nim_status/c/nim_status.nim` represent a
hybrid of `go/shim.nim` and `lib/shim.nim`. Again, the goal is that over time
more and more `proc`s implemented in Nim replace the shims around status-go.
Callers that don't need to consume return values formatted according to
status-go conventions can use `lib.nim` directly, e.g. via `import
nim_status/lib` or by compiling `src/nim_status/c/lib.nim` and linking/calling
from C.
`c_malloc` has been copied (in `src/nim_status/c/sys.nim`) from the source of
Nim's `system/ansi_c` because `ansi_c` is an undocumented internal API.
A Nim template or pragma might be useful with respect to usgae of `c_malloc` in
`src/nim_status/c/*`, i.e. to cut down on repetition.
Use of `{.exportc.}` is limited to the `src/nim_status/c/nim_status.nim` hybrid
shim to avoid imposing exported symbols on C-oriented library consumers who may
wish to compose things in a different manner.
With respect to the Nim implementation of `hashMessage`, both Nim-oriented and
C-oriented tests have been implemented. Whether doubling up the tests is really
necessary/desirable for all `proc`s is probably worth discussing.
Adjust `.gitignore` and refactor `Makefile` accordingly; apply some lessons
learned while working on [status-im/nim-status-client][nsc].
Closes #34.
[shim-strat]: https://github.com/status-im/nim-status/issues/5#issuecomment-647497745
[sgo]: https://github.com/status-im/status-go
[nsc]: https://github.com/status-im/nim-status-client
2020-07-23 22:15:09 +00:00
|
|
|
tests-nim: | $(STATUSGO)
|
2020-08-10 16:48:30 +00:00
|
|
|
ifeq ($(detected_OS),Darwin)
|
2020-07-13 14:26:31 +00:00
|
|
|
$(ENV_SCRIPT) nimble test
|
2020-08-10 16:48:30 +00:00
|
|
|
else ifeq ($(detected_OS),Windows)
|
2020-09-01 22:53:17 +00:00
|
|
|
PATH="$(STATUSGO_LIBDIR):$(NIM_WINDOWS_PREBUILT_DLLDIR):/usr/bin:/bin:$$PATH" \
|
2020-08-10 16:48:30 +00:00
|
|
|
$(ENV_SCRIPT) nimble test
|
|
|
|
|
else
|
|
|
|
|
LD_LIBRARY_PATH="$(STATUSGO_LIBDIR)" \
|
|
|
|
|
$(ENV_SCRIPT) nimble test
|
|
|
|
|
endif
|
2020-07-02 18:40:49 +00:00
|
|
|
|
feat: introduce Nim impl of hashMessage in reorganized library
Introduce a Nim implementation of `hashMessage` situated in a reorganized
library with *Nim-oriented* and *C-oriented* entry points inspired by the
[shim strategy][shim-strat] suggested by @arnetheduck.
The goal of this approach (per @iurimatias, at least as I understood what was
discussed and tasked) is for Nim implementations of equivalent functionality to
eventually supersede existing [status-go][sgo] implementations.
These changes will benefit from feedback by @arnetheduck, @zah,
@stefantalpalaru, @siphiuel, other members of stimbus/desktop, et al. – my dev
experiences with Nim and C are quite limited to date. Some of the changes may
be problematic, unnecessary, suboptimal, etc. I may have reified the *"shim
strategy"* badly. Please shred this PR apart and lead me to the 💡
light. Thanks for your help!
N.B. `tests/nim/login.nim` and `tests/c/login.c` use loops that never
terminate (introduced prior to this PR). Future work will attempt to remedy
that shortcoming but it's out of scope for this PR.
The reorganized library can be grouped into two trees of `.nim` sources, but
note that `import` statements interlink some of them.
**Nim-oriented**
```
├── src
│ ├── nim_status
│ │ ├── go
│ │ │ └── shim.nim
│ │ ├── lib
│ │ │ ├── shim.nim
│ │ │ └── util.nim
│ │ ├── lib.nim
│ │ └── types.nim
│ └── nim_status.nim
```
**C-oriented**
```
├── src
│ ├── nim_status
│ │ ├── c
│ │ │ ├── go
│ │ │ │ └── shim.nim
│ │ │ ├── lib
│ │ │ │ └── shim.nim
│ │ │ ├── lib.nim
│ │ │ ├── nim_status.nim
│ │ │ └── sys.nim
```
The key difference between the Nim sources in one tree and the other is that
the Nim-oriented sources are intended to be consumed by other Nim
sources (e.g. [status-im/nim-status-client][nsc] via Nim's built-in `import`),
while the C-oriented sources are intended to be compiled to a C
library (e.g. `nim_status.a`) and then linked/called by other C code. To that
end, the former use e.g. `string` in call signatures while the latter use
`cstring`. Along the same lines, the C-oriented `proc`s may return pointers to
memory allocated with `c_malloc` such that it's up to the caller to free the
memory occupied by the return values.
Both `src/nim_status/go/shim.nim` and `src/nim_status/c/go/shim.nim` are pure
shims around status-go, the main difference being their call signatures.
With `src/nim_status/lib.nim` the intention is to implement functionality in a
manner independent of status-go's idioms.
In `src/nim_status/[c/]lib/shim.nim` the intention is to wrap around
`src/nim_status/lib.nim` in a way that preserves status-go's call signatures
and formatting. For example, the `hashMessage` proc introduced in this PR in
`src/nim_status/lib.nim` returns a hex string like `0xabcd...` while
`lib/shim.nim` returns JSON that's a match for status-go:
`{"result":"0xabcd..."}`.
Both `src/nim_status.nim` and `src/nim_status/c/nim_status.nim` represent a
hybrid of `go/shim.nim` and `lib/shim.nim`. Again, the goal is that over time
more and more `proc`s implemented in Nim replace the shims around status-go.
Callers that don't need to consume return values formatted according to
status-go conventions can use `lib.nim` directly, e.g. via `import
nim_status/lib` or by compiling `src/nim_status/c/lib.nim` and linking/calling
from C.
`c_malloc` has been copied (in `src/nim_status/c/sys.nim`) from the source of
Nim's `system/ansi_c` because `ansi_c` is an undocumented internal API.
A Nim template or pragma might be useful with respect to usgae of `c_malloc` in
`src/nim_status/c/*`, i.e. to cut down on repetition.
Use of `{.exportc.}` is limited to the `src/nim_status/c/nim_status.nim` hybrid
shim to avoid imposing exported symbols on C-oriented library consumers who may
wish to compose things in a different manner.
With respect to the Nim implementation of `hashMessage`, both Nim-oriented and
C-oriented tests have been implemented. Whether doubling up the tests is really
necessary/desirable for all `proc`s is probably worth discussing.
Adjust `.gitignore` and refactor `Makefile` accordingly; apply some lessons
learned while working on [status-im/nim-status-client][nsc].
Closes #34.
[shim-strat]: https://github.com/status-im/nim-status/issues/5#issuecomment-647497745
[sgo]: https://github.com/status-im/status-go
[nsc]: https://github.com/status-im/nim-status-client
2020-07-23 22:15:09 +00:00
|
|
|
tests: tests-nim tests-c
|
|
|
|
|
|
|
|
|
|
test: tests
|
|
|
|
|
|
|
|
|
|
clean: | clean-common clean-build-dirs clean-data-dirs
|
|
|
|
|
rm -rf $(STATUSGO)
|
|
|
|
|
rm -rf bottles
|
2020-08-10 16:48:30 +00:00
|
|
|
rm -rf DLLs
|
feat: introduce Nim impl of hashMessage in reorganized library
Introduce a Nim implementation of `hashMessage` situated in a reorganized
library with *Nim-oriented* and *C-oriented* entry points inspired by the
[shim strategy][shim-strat] suggested by @arnetheduck.
The goal of this approach (per @iurimatias, at least as I understood what was
discussed and tasked) is for Nim implementations of equivalent functionality to
eventually supersede existing [status-go][sgo] implementations.
These changes will benefit from feedback by @arnetheduck, @zah,
@stefantalpalaru, @siphiuel, other members of stimbus/desktop, et al. – my dev
experiences with Nim and C are quite limited to date. Some of the changes may
be problematic, unnecessary, suboptimal, etc. I may have reified the *"shim
strategy"* badly. Please shred this PR apart and lead me to the 💡
light. Thanks for your help!
N.B. `tests/nim/login.nim` and `tests/c/login.c` use loops that never
terminate (introduced prior to this PR). Future work will attempt to remedy
that shortcoming but it's out of scope for this PR.
The reorganized library can be grouped into two trees of `.nim` sources, but
note that `import` statements interlink some of them.
**Nim-oriented**
```
├── src
│ ├── nim_status
│ │ ├── go
│ │ │ └── shim.nim
│ │ ├── lib
│ │ │ ├── shim.nim
│ │ │ └── util.nim
│ │ ├── lib.nim
│ │ └── types.nim
│ └── nim_status.nim
```
**C-oriented**
```
├── src
│ ├── nim_status
│ │ ├── c
│ │ │ ├── go
│ │ │ │ └── shim.nim
│ │ │ ├── lib
│ │ │ │ └── shim.nim
│ │ │ ├── lib.nim
│ │ │ ├── nim_status.nim
│ │ │ └── sys.nim
```
The key difference between the Nim sources in one tree and the other is that
the Nim-oriented sources are intended to be consumed by other Nim
sources (e.g. [status-im/nim-status-client][nsc] via Nim's built-in `import`),
while the C-oriented sources are intended to be compiled to a C
library (e.g. `nim_status.a`) and then linked/called by other C code. To that
end, the former use e.g. `string` in call signatures while the latter use
`cstring`. Along the same lines, the C-oriented `proc`s may return pointers to
memory allocated with `c_malloc` such that it's up to the caller to free the
memory occupied by the return values.
Both `src/nim_status/go/shim.nim` and `src/nim_status/c/go/shim.nim` are pure
shims around status-go, the main difference being their call signatures.
With `src/nim_status/lib.nim` the intention is to implement functionality in a
manner independent of status-go's idioms.
In `src/nim_status/[c/]lib/shim.nim` the intention is to wrap around
`src/nim_status/lib.nim` in a way that preserves status-go's call signatures
and formatting. For example, the `hashMessage` proc introduced in this PR in
`src/nim_status/lib.nim` returns a hex string like `0xabcd...` while
`lib/shim.nim` returns JSON that's a match for status-go:
`{"result":"0xabcd..."}`.
Both `src/nim_status.nim` and `src/nim_status/c/nim_status.nim` represent a
hybrid of `go/shim.nim` and `lib/shim.nim`. Again, the goal is that over time
more and more `proc`s implemented in Nim replace the shims around status-go.
Callers that don't need to consume return values formatted according to
status-go conventions can use `lib.nim` directly, e.g. via `import
nim_status/lib` or by compiling `src/nim_status/c/lib.nim` and linking/calling
from C.
`c_malloc` has been copied (in `src/nim_status/c/sys.nim`) from the source of
Nim's `system/ansi_c` because `ansi_c` is an undocumented internal API.
A Nim template or pragma might be useful with respect to usgae of `c_malloc` in
`src/nim_status/c/*`, i.e. to cut down on repetition.
Use of `{.exportc.}` is limited to the `src/nim_status/c/nim_status.nim` hybrid
shim to avoid imposing exported symbols on C-oriented library consumers who may
wish to compose things in a different manner.
With respect to the Nim implementation of `hashMessage`, both Nim-oriented and
C-oriented tests have been implemented. Whether doubling up the tests is really
necessary/desirable for all `proc`s is probably worth discussing.
Adjust `.gitignore` and refactor `Makefile` accordingly; apply some lessons
learned while working on [status-im/nim-status-client][nsc].
Closes #34.
[shim-strat]: https://github.com/status-im/nim-status/issues/5#issuecomment-647497745
[sgo]: https://github.com/status-im/status-go
[nsc]: https://github.com/status-im/nim-status-client
2020-07-23 22:15:09 +00:00
|
|
|
|
|
|
|
|
clean-build-dirs:
|
|
|
|
|
rm -rf build/*
|
|
|
|
|
rm -rf tests/c/build/*
|
|
|
|
|
rm -rf tests/nim/build/*
|
|
|
|
|
|
|
|
|
|
clean-data-dirs:
|
|
|
|
|
rm -rf data
|
|
|
|
|
rm -rf keystore
|
|
|
|
|
rm -rf noBackup
|
|
|
|
|
|
|
|
|
|
create-data-dirs:
|
|
|
|
|
mkdir -p data
|
|
|
|
|
mkdir -p keystore
|
|
|
|
|
mkdir -p noBackup
|
|
|
|
|
|
2020-07-02 13:20:16 +00:00
|
|
|
endif # "variables.mk" was not included
|
